[
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) ?!?
|
thanks for the explaination. so platform bypasses oomph for the
inital asm new version introduction
Am 07.04.22 um 07:54 schrieb Ed Merks:
Christian,
Thanks for the quick answer.
With respect to the Platform using Oomph it's more that the
Platform can use Oomph and there are setups that work well for
using Oomph targlets such that it actually does use Oomph, if
and only if the setups are used. But that works because the
targlets point at the p2 repositories for the Platform's own
builds such that any newly introduced IUs are available because
the most recent IBuild put them in a repository.
I will experiment with how one might consume from Maven and get
the results into a p2 repository. Like this can be made very
streamlined and easy...
On 07.04.2022 07:48, Dietrich,
Christian wrote:
answers inline
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@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
-e 6
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@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
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
--
Christian Dietrich (Diplom-Informatiker (BA))
Softwareentwickler / -Architekt
Committer and Co-Lead for Eclipse Xtext
Tel.: +49 (0) 711 / 34 21 91-0
Fax.: +49 (0) 711 / 34 21 91-29
Mobil: +49 (0) 151 / 173969 17
Mail: christian.dietrich@xxxxxxxxx
XING: https://www.xing.com/profile/Christian_Dietrich8
Web: http://www.itemis.de
Skype: christiandietrich1982
itemis AG
Niederlassung Süd
Industriestraß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