Re: [cross-project-issues-dev] PlatformRel vs SimRel vs Orbit Abolishmen

[Ed Merks <ed.merks@xxxxxxxxx>]

Christoph,

Oomph provides Targlets, a target location implementation, just like PDE 
does and now m2e does.   There are a number of very significant 
advantages to the Targlet approach as outlined here:

https://wiki.eclipse.org/Oomph_Targlets

This support also includes the ability to generate a *.target file for 
use in the Maven.

So consumers would like to see the ability to express Maven dependencies 
directly within Targlets as is supported by m2e. Hopefully m2e can be 
leveraged to implement that, but I wouldn't be surprised if there is 
little in the way of "API" for reusing the implementation details.

On 07.04.2022 07:00, Christoph Läubrich wrote:
> Hi Christian,
>
> first of all I could understand that its frustrating if one feels 
> actually overwhelmed by releng tasks but I think you are not alone 
> with that.
>
> So the same applies for people managing the releng tasks for orbit and 
> platform and this was taken in the past and for sure it was 
> comfortable for the consumers but I think we have reached a point 
> where it becomes prominent that it is hard to keep up with this 
> good-old times:
>
> - serve CVEs impacting a lot of projects arise every day and we need 
> to become faster here, there are often huge delays until they show up 
> in orbit, with log4shell the update was outdated a few hours later 
> because of another important CVE fixed and so on
> - New Java versions are released a lot more often and many OSS 
> projects don't want to take the effort to support older versions
>
> For supporting old versions, as you have written, this is a choice of 
> the project and I honestly don't understand the complains, for me 
> there are two options:
>
> 1) drop the support for old versions and if no one complains be happy 
> about saving you a lot of useless effort
> 2) if users are really addicted to old versions ask them to help with 
> supporting that or pay for it so you can acquire more resources
>
> Interestingly, for platform often there *are* complains but asking for 
> someone to step up and help often results in silence... in the end it 
> was not /that/ impossible to upgrade.
>
> About the OOMPH part (as it was already mentioned twice here) I'm a 
> bit confused, from what I understand OOMPH is based on eclipse so it 
> could pull in whats necessary from the m2e bundles and should all be 
> set for the new target location types (that what these extension 
> points are for isn't it?). If anything hinders us to do so we should 
> find a solution for that instead of waiting to implement just another 
> implementation of the same thing.
>
> As a last note:
> As Xtext is an eclipse project you can always request Orbit of adding 
> *any* dependency but be aware that this must be driven by you (e.g 
> providing patches).
>
>
>
> Am 07.04.22 um 04:54 schrieb Christian Dietrich:
> > 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
> >
> > Projects and values:
> > - Some projects value support for older platform and java versions, 
> > others dont
> > - Some projects "pay attention", others dont
> >
> > 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
> >    - ....
> >
> > 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.
> >
> > 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.
> >
> > So if Xtext uses ASM and Platform/JDT uses ASM and they should work 
> > together we need to uses the same ASM.
> > 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.
> > - Alternatively we can stop supporting more than 1 platform or Java 
> > versions.
> >
> > 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.
> >
> > 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
> >
> > 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.
> >
> > Thanks and regards
> > Christian
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit 
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev