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.
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.
- Joakim
On Thu, Apr 7,
2022 at 1:46 AM Aleksandar Kurtakov <akurtako@xxxxxxxxxx>
wrote:
On Thu,
Apr 7, 2022 at 9:30 AM Aleksandar
Kurtakov <akurtako@xxxxxxxxxx>
wrote:
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.
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.
Would that help at least partially
address your current concerns?
Or
is there something that's broken
even with that approach?