[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [cross-project-issues-dev] PlatformRel vs SimRel vs Orbit Abolishment frustration / Xtext leaving SimRel (again) ?!?
|
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