|Re: [cross-project-issues-dev] PlatformRel vs SimRel vs Orbit Abolishment frustration / Xtext leaving SimRel (again) ?!?|
Christian,I share your frustrations. Yes, much is being done to make life easier and/or better (direct Maven consumption and Github with github issues) but somehow every change is also disruptive and very often time consuming such that you much spend time on what feels like a gigantic no-op...
More comments below. On 07.04.2022 04:54, Christian Dietrich wrote:
Hi all, my frustration of the current state has cost me another sleepless night and thus i need to start this discussion again.All of the following statements are subjective and describe my personal view and option and feelings.Trigger was https://www.eclipse.org/lists/cross-project-issues-dev/msg19066.html but is just another big drop to barrel to overflow.What is it about:- PlatformRel: Release of the basic eclipse platform and jdt on a regular basis - SimRel: All project release together with PlatformRel in versions that work together. This requires the projects to "paying attention" to ensure this holds true. - Orbit: Central place to pull 3rd dependencies from. This avoid each and every project packaging their own stuff and makes it possible for projects with the same dependency to work together seemlessly.Projects: Eclipse has projects with - some budget - a limited budget (i would categeorize Xtext with 4-6 days a month here) - basically no buget
EMF, XSD, JustJ and Oomph have been budget free for close to 2 years.
EMF tests against Helios. I had been trying to keep Oomph running on Juno, but that was no longer possible with all the nice though disruptive p2 changes for PGP. JustJ keeps up with new Adoptium releases; I'm currently testing Java 18.Projects and values:- Some projects value support for older platform and java versions, others dont- Some projects "pay attention", others dont
Working with the community and as a community is key. So I'm not so happy to see comments like "That's more the problem of SimRel" as if we aren't all part of the same community. I know it's not fair to expect the Platform to solve world hunger, but treating world hunger as someone else's problem is questionable.Xtext: what do i do for Xtext - work with community - fix bug - develop some smaller features - pay attention - fix broken Jenkins files cause infrastructure changes - test against upstream platform and jdt - bump versions of 3rd party dependencies - contribute to upstream project - ....
I know Xtext in particular is used in a vast downstream ecosystem and I know that this consumption makes all the projects upstream from Xtext, including EMF and the Platform more relevant to a broader community. So we should all be concerned about Xtext's welfare. In addition to that, somehow Xtext's downstream ecosystem needs to be leveraged to sponsor these activities, and therein lies a major point of failure.
Yes, welcome to my world. It's almost impossible to find time to work on new things in my own technologies.What makes me frustrated:I have the feeling that i spend 95% of my buget to accommodate for upstream infrastructure changes so that there is basically no time left for bugfixes or features. The 3 month simrel also adds time pressure to that "paying attention" if you take it serious.
Yes, this doesn't feel like a community decision, does it? And in the end, Orbit can't be abolished because not all things are available as OSGi bundles in Orbit.The trigger(s):- https://bugs.eclipse.org/bugs/show_bug.cgi?id=568936 with a cleanup process in orbit we have to deal with stuff disappearing from orbit. it is clear that this is a debt in orbit and i am ok with spending a 2/3 month worth of budget to accomodate for it. - https://www.eclipse.org/lists/cross-project-issues-dev/msg19066.html / https://bugs.eclipse.org/bugs/show_bug.cgi?id=579574the 2nd one is the defacto abolishment of orbit.
So if Xtext uses ASM and Platform/JDT uses ASM and they should work together we need to uses the same ASM.
The topic here: https://github.com/eclipse-pde/eclipse.pde.ui/issues/11And here the issue is perhaps also the renaming of the bundle to use the direct Maven name. Does PDE's decision also make the decision for JDT? I don't know...
What does this mean for Xtext- We need to be able to support older platforms and java versions with newer tycho versions + the work for Jenkins file to make this possible (8 different builds) - We need to find out how to use the p2 maven feature from oomph (at a first glance i could not find an option) or replace oomph with target files.
I hope someone will step forward to sponsor this feature; it looks some promising that this will be the case...
I think the issue here is mostly that you need bundles in a p2 repo, right?
- Alternatively we can stop supporting more than 1 platform or Java versions.That would provide less value to your consumers and make new versions less consumable and less relevant. I very often see very old Platform versions being used because with all the great changes and evolutions in the Platform, also come regressions and breaking changes that hinder adoption and potentially lead to dropping adoption altogether...
I cannot tell how much work this will be because i am neither a tycho nor a Jenkinsfile nor an Oomph expert. I also have no pointers where to copy & paste from to make my life easier with that.
Perhaps there are some things I can do to help?
What specifically is leading to this inability to support older versions in this specific case? What can be done to mitigate that?So i dont know if i can make this possible with the budget i have (even less i can imagine projects with much less budget can do)So what can i do: - support only latest greated and pass the ball downstream
- pull Xtext out of simrel and with it all of its dependencies (that would also include lsp4e for example)
- stay in simrel but stop "paying attention" and if stuff works together
Would Xtext still work on the latest if you did nothing?
Alternatives:- why no keep orbit as place for 3rd party dependencies. I dont know what would need to be done to make use of the p2 maven feature there instead in the projects on their own.
Perhaps a middle ground would be to build/provide an Orbit-like repo that pulls things from Maven and publishes them in the p2 repository. Apparently this is so easy to do, each project should do it itself. But if it's so easy to do, "we" could also do that in a central place as a service to SimRel and to the broader community. If the Platform doesn't want to do that, help with that, nor consume from that, that doesn't prevent providing the same 3rd party Maven bundles being provided/consumed/used by the Platform...
Would that help at least partially address your current concerns? Or is there something that's broken even with that approach?
Thanks and regards Christian
Back to the top