[
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) ?!?
|
i cannot even reproduce this using java18
mvn ebr:create-recipe -DgroupId=org.antlr
-DartifactId=antlr-runtime -Dversion=3.5.2
-DbundleSymbolicName=org.antlr.runtime -Dmaven.repo.local=.m2
Am 07.04.22 um 14:02 schrieb Aleksandar
Kurtakov:
Regarding your JDK 17/18 support and your aQute
issue.
[INFO] --- ebr-maven-plugin:1.4.0-SNAPSHOT:bundle
(default-bundle) @ org.antlr.runtime ---
[INFO] Gathering dependencies
[INFO] Configured Artifact:
org.antlr:antlr-runtime:3.5.2:jar
[INFO] Unpacking
/home/akurtakov/.m2/repository/org/antlr/antlr-runtime/3.5.2/antlr-runtime-3.5.2.jar
to
/home/akurtakov/git/orbit-recipes/antlr/org.antlr.runtime_3.5.2/target/dependency-bin
with includes "**/*" and excludes
"META-INF/maven/**/*.*"
[INFO] Merging collected dependencies
[INFO] Using 'UTF-8' encoding to copy filtered
resources.
[INFO] Copying 118 resources
[INFO] Generating OSGi MANIFEST.MF
[ERROR] An internal error occurred
java.util.ConcurrentModificationException
at java.util.TreeMap.callMappingFunctionWithCheck
(TreeMap.java:750)
at java.util.TreeMap.computeIfAbsent
(TreeMap.java:604)
at aQute.bnd.osgi.Jar.putResource (Jar.java:288)
at aQute.bnd.osgi.Jar$1.visitFile (Jar.java:202)
at aQute.bnd.osgi.Jar$1.visitFile (Jar.java:177)
at java.nio.file.Files.walkFileTree
(Files.java:2811)
at aQute.bnd.osgi.Jar.buildFromDirectory
(Jar.java:176)
at aQute.bnd.osgi.Jar.<init> (Jar.java:119)
at aQute.bnd.osgi.Jar.<init> (Jar.java:172)
at
org.apache.felix.bundleplugin.BundlePlugin.getOSGiBuilder
(BundlePlugin.java:604)
at
org.apache.felix.bundleplugin.ManifestPlugin.getAnalyzer
(ManifestPlugin.java:285)
at
org.apache.felix.bundleplugin.ManifestPlugin.execute
(ManifestPlugin.java:111)
at org.eclipse.ebr.maven.BundleMojo.buildBundle
(BundleMojo.java:358)
at org.eclipse.ebr.maven.BundleMojo.execute
(BundleMojo.java:462)
This is because of an old biz.aQute.bnd lib.
Eclipse Jetty hit this same issue early, during the
Java-17 Early Access builds.
We build all the way up to Java-19 EA now.
Update your biz.aQute.bndlib to version 5.3.0
<dependency>
<groupId>biz.aQute.bnd</groupId>
<artifactId>biz.aQute.bndlib</artifactId>
<version>5.3.0</version>
</dependency>
If you manage the ebr-maven-plugin, then update it
there.
Otherwise, if you are a simple project using the
ebr-maven-plugin, the above dependency in a
<dependencyManagement> should be sufficient.
I just don't have the energy to try saving things
anymore, if it's important enough for many people - it will
get saved! Thanks for your hints though!
Btw, we LOVE the new Tycho maven P2 repo featureset.
It's eliminated a big headache on our releases.
We were spending on a good day about 6+ man hours to
get an old school P2 repo out per release.
On a problematic release it could easily top 40 man
hours per release (ugh!).
Now it's brain dead simple and just works, with an
occasional bump in the Tycho version being used, which
is automatically reported to us via the github tooling.
Exactly my experience and I hear/see the same comments
everywhere people did the change. The more people showing
their success stories the better to show the real gains.
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.
> 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?
> - 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?
>
> 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?
> 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.
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...
As someone who did a fair part of that
work on Platform behalf, down to maintaining
Orbit bundles, even keeping Orbit and EBR
releng working at times and etc. - to me
Orbit just proved to be extra step for no
benefit with very few people stepping up to
share the burden so the choice had to be
made - do the work directly and skip the
time consuming extra steps or let Platform
suffer (we are already far behind on many
dependencies which has the issue that we
ship deps with CVEs(e.g.
commons-fileupload), no support from
upstream and etc.). Now that I've seen the
faster and easier path I don't see much
point in doing this extra work as once this
happens I would be left to deal with it on
my own again as history has shown to me.
Let me add to the reasons why Orbit/EBR is no
longer a go from my side. Last week I tried
working on adding Lucene 9 to it but local build
failed with:
[INFO] ---
ebr-maven-plugin:1.4.0-SNAPSHOT:bundle
(default-bundle) @ org.antlr.runtime ---
[INFO] Gathering dependencies
[INFO] Configured Artifact:
org.antlr:antlr-runtime:3.5.2:jar
[INFO] Unpacking
/home/akurtakov/.m2/repository/org/antlr/antlr-runtime/3.5.2/antlr-runtime-3.5.2.jar
to
/home/akurtakov/git/orbit-recipes/antlr/org.antlr.runtime_3.5.2/target/dependency-bin
with includes "**/*" and excludes
"META-INF/maven/**/*.*"
[INFO] Merging collected dependencies
[INFO] Using 'UTF-8' encoding to copy filtered
resources.
[INFO] Copying 118 resources
[INFO] Generating OSGi MANIFEST.MF
[ERROR] An internal error occurred
java.util.ConcurrentModificationException
at
java.util.TreeMap.callMappingFunctionWithCheck
(TreeMap.java:750)
at java.util.TreeMap.computeIfAbsent
(TreeMap.java:604)
at aQute.bnd.osgi.Jar.putResource
(Jar.java:288)
at aQute.bnd.osgi.Jar$1.visitFile
(Jar.java:202)
at aQute.bnd.osgi.Jar$1.visitFile
(Jar.java:177)
at java.nio.file.Files.walkFileTree
(Files.java:2811)
at aQute.bnd.osgi.Jar.buildFromDirectory
(Jar.java:176)
at aQute.bnd.osgi.Jar.<init>
(Jar.java:119)
at aQute.bnd.osgi.Jar.<init>
(Jar.java:172)
at
org.apache.felix.bundleplugin.BundlePlugin.getOSGiBuilder
(BundlePlugin.java:604)
at
org.apache.felix.bundleplugin.ManifestPlugin.getAnalyzer
(ManifestPlugin.java:285)
at
org.apache.felix.bundleplugin.ManifestPlugin.execute
(ManifestPlugin.java:111)
at
org.eclipse.ebr.maven.BundleMojo.buildBundle
(BundleMojo.java:358)
at org.eclipse.ebr.maven.BundleMojo.execute
(BundleMojo.java:462)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
(DefaultBuildPluginManager.java:137)
at
org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
(MojoExecutor.java:301)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:211)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:165)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:157)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:121)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:81)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
(SingleThreadedBuilder.java:56)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute
(LifecycleStarter.java:127)
at org.apache.maven.DefaultMaven.doExecute
(DefaultMaven.java:294)
at org.apache.maven.DefaultMaven.doExecute
(DefaultMaven.java:192)
at org.apache.maven.DefaultMaven.execute
(DefaultMaven.java:105)
at org.apache.maven.cli.MavenCli.execute
(MavenCli.java:960)
at org.apache.maven.cli.MavenCli.doMain
(MavenCli.java:293)
at org.apache.maven.cli.MavenCli.main
(MavenCli.java:196)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0
(Native Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:77)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke
(Method.java:568)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
(Launcher.java:282)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch
(Launcher.java:225)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
(Launcher.java:406)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main
(Launcher.java:347)
So if I want to use Orbit am I on my own to
make EBR work with Java 17/18? Or should I be the
one flipping configs/paths/etc. for every
different task I have to do? That way it's plain
impossible to do any work. And yes, I do make sure
that Eclipse works just fine on latest JVM so it's
my top priority so can't afford to stick to old
JVM as default.
If one wants Orbit to still be considered
seriously someone should step up and make it
actually work for all of us (if possible at all
with fast moving Java versions!) and I can assure
you that I tried (
https://github.com/eclipse/ebr/commits?author=akurtakov)
but there are just that many hours in the day and
this happened to be lost cause from the interest
I've seem from the community.
--
Aleksandar Kurtakov
Red Hat Eclipse Team
--
Aleksandar Kurtakov
Red Hat Eclipse Team
_______________________________________________
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
--
Aleksandar Kurtakov
Red Hat Eclipse Team
_______________________________________________
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