-
Notifications
You must be signed in to change notification settings - Fork 321
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Xtext leaving Eclipse simultaneous release with 2023-06 #1961
Comments
I also want to add a few personal words to the Blogpost published at itemis. For me personally this is a necessary step out of a very sad situation. I started with Xtext as a user, became an expert on it while answering forum questions and using Xtext in more and more projects. In 2016 I became a part of the newly formed Xtext team at itemis and grew into the position of a committer and later a project lead. I had the chance to work with great people and I want to thank the whole team for their work and especially Sebastian for the good collaboration and support. The situation described above bothered me more and more over the last years and I felt burned out and bored out at the same time and I had to do something about that. The future will tell if another party will step up and take over the work to keep Xtext on the simrel train or if the Xtext framework will continue to live and prosper outside of the Eclipse simrel. Christian |
I think that many of the Eclipse Modeling projects find the 3 month cadence excessive. Certainly OCL, QVTd, QVTo and MoDisco would happily fall in line with a reversion to a 12 month cadence with strongly API compatible ad hoc maintenance releases when merited. Leaving SimRel is not that clever since while in the short term the pain of dealing with the latest EF infrastructure ' improvement' is eliminated, just as soon as you want to re-align you will need to incur the pain after all. SimRel is also much the easiest way for users to install. |
It is probably more accurate to say SimRel would be the easiest way to install, if it worked. As far as I know, the only way to get xtext 25.0 working in 21-03 is to not set the xtext nature on a project, and do all the code generation externally (e.g. from maven). That way, using the xtext-dev-bom, you are tracking the version of emf that xtext is actually tested against, rather than whatever p2 decides you would be better off with. See e.g. eclipse/xtext-maven#71 |
This is not correct. I have working installations with 2.25 across various Eclipse versions including 2021-03 and the nightly platform builds of of 2021-06 Which failure do you see in your environment? Can you please make a dedicated ticket? |
see #1963 |
still an issue. we are still struggling to keep pace |
with the (potential) abolishment of orbit on the horizon this may become relevant again: |
Xtext is not the only one that will have to abandon SimRel if Orbit vanishes. e.g. at least OCL, QVTo, QVTd, MoDisco too. I must confess that I fail to see why someone, presumably the EF, is creating so many difficulties for us. If something has to change then the EF should be providing the solution, not the problem. |
Can we close this issue for the time being? |
I want to inform you that we at itemis will no longer drive the participation of Xtext in the Eclipse simultaneous release beginning with the upcoming 2021-06 release https://blogs.itemis.com/en/xtext-is-leaving-the-eclipse-simultaneous-release
As there are currently no other parties with the capacity to take over the work this will result in Xtext leaving the Simrel. This will also affect other projects in the Simrel that consume Xtext like OCL, Xcore, Parsley, viatra, sirius and parts of LSP4j, GEF and papyrus, QVTD as well as the DSL Package in EPP (and maybe others).
The text was updated successfully, but these errors were encountered: