ASM, Guice and Guava can be accommodated by losing the upper
version bound; they appear to have good compatibility for at least
my trivial usages. The explicit upper bound is honest in that it
indicates not-tested, but a blocker for anyone who wants to try
and test it.
The real killers for project relengs are the platform's
gratuitous removal of IPlatformRunnable, movement to Java 11 BREE
coupled with Tycho evolution.
Exactly, thanks again for proving my point - Java 9 imposed one set of changes, Java 11 additional, Java 14 additional, Java 16 additional and even more expected with Java 17. With literally 3 people looking at Tycho issues with priority being after Eclipse Platform, WildWebDeveloper, M2E, Corrosion, Linux Tools and so on and on it's an achievement that Tycho is working on so big a number of environments/jvms.
I want to be perfectly clear about expectations if Tycho is left with current manpower - latest Java and latest LTS Java. I know this has implications on everyone but my time is as scarce as everyone else's and just like everyone else I have to do what I'm paid for - release Eclipse platform that supports latest Java and latest LTS Java. And tycho is just a means to achieve that!
I would very much welcome others joining on daily tasks so we share the burden and wider compatibility is preserved. I'm willing to transfer whatever extra power one thinks I have on any such decision and let that person show us (and teach me!) how to achieve better results in current circumstances!
troublesome are the almost
six monthly breakages of the EF IT infrastructure as service is
'improved'.
Regards
Ed Willink
On 26/03/2021 07:24, Christian Dietrich
wrote:
yes we can keep it unless some new ASM, Guice, Guava, Junit5 or
another "paying attention" topic forces us to act and build
milestones and releases with the 3 weeks pressure.
Am 26.03.21 um 08:20 schrieb Ed
Merks:
All,
I've been tempted for quite some time to make a similar
announcement, only for EMF. I don't believe I will have the
resource to get EMF's build working on the new infrastructure,
and most certainly I am highly unlikely to do so without some
evidence that the cost and effort involved will *not *be born
only by me personally (and by the helpful-but-overburdened
Foundation Staff):
I *strongly *recommend to the IDE Working Group that action be
taken without further delay.
Christian,
One thing that I would ask, and strongly suggest for Xtext, is
simply to leave your current contribution(s) to SimRel as is for
contribution to 2021-06 such that the IDE Working Group has time
to take action. There is no absolute requirement that you must
provide a new release, right? Certainly one would hope that
it's reasonable to assume that the Platform, and your other
dependencies, will remain fully compatible with your most
recently release, right?
Physically removing the most recent Xtext release from the
2021-06 train is a bit of a bombshell that affects a great many
other projects. Once we drop this bomb, we may as well throw in
the towel...
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 and parts of GEF
as well as the DSL Package in EPP. (and maybe others)
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, Stephan Grollmann
Sitz der Gesellschaft/Registered Office: Am Brambusch 15-24,
44536 Lünen (Germany)
Registergericht/Registry Court: Amtsgericht Dortmund | HRB
20621