answers inline Am Do., 7. Apr. 2022 um 07:34 Uhr schrieb Ed Merks <ed.me...@gmail.com>:
> 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. > > > > Projects and values: > > - Some projects value support for older platform and java versions, > > others dont > > - Some projects "pay attention", others dont > > > 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. > > > 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 > > - .... > > > 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. > > 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 this is why i want to avoid the move of dropping out > > > 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, welcome to my world. It's almost impossible to find time to work > on new things in my own technologies. > > > > 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=579574 > > > > the 2nd one is the defacto abolishment of orbit. > 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. > > > > 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/11 > > And 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? > yes. without we need to solve the "dont use tycho 1.7 anymore" and the "get it in our oomph target platform" problem > > > - 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? > for oomph we would need the feature to have support for the m2 dependencies but as you already indicated that is not there yet what i dont understand yet is how platform uses oomph but avoids the problem. for tycho and Jenkinsfile we would need: have java 8 builds with tycho 2.7.x and for jenkinsfile: how to set this up with toolchains etc > > > > 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 > What specifically is leading to this inability to support older versions > in this specific case? What can be done to mitigate that? > > - pull Xtext out of simrel and with it all of its dependencies (that > > would also include lsp4e for example) > No please. > > - stay in simrel but stop "paying attention" and if stuff works together > > > Would Xtext still work on the latest if you did nothing? > it would work, but only if downstream clients dont mix Xtext code that uses ASM 9.2 with Platform code that uses ASM 9.3 > > 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. yes. this would be: move the consume maven p2 part to orbit instead of single projects but platform does not seem to want to go over orbit at all. > > 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? > my assumtion is that when i have a p2 repo i can consume 3rd party from i just use that repo and using e.g. asm 9.3 can be done in a few hours (inclusing all build times for different repos etc) so it would solve the urgent problem. > > > Thanks and regards > > Christian > > > _______________________________________________ > cross-project-issues-dev mailing list > cross-project-issues-dev@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev > -e 6 70565 Stuttgart -- Vorstand/Board: Jens Wagener (Vors./chairman), Dr. Stephan Eberle, Abdelghani El-Kacimi, Wolfgang Neuhaus, Franz-Josef Schuermann Aufsichtsrat/Supervisory Board: Michael Neuhaus (Vors./chairman), Harald Goertz, Eric Swehla Sitz der Gesellschaft/Registered Office: Am Brambusch 15-24, 44536 Lünen (Germany) Registergericht/Registry Court: Amtsgericht Dortmund | HRB 20621
_______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
