On Thu, Apr 7, 2022 at 2:12 PM Joakim Erdfelt
<joakim.erdf...@gmail.com> wrote:
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.
- Joakim
On Thu, Apr 7, 2022 at 1:46 AM Aleksandar Kurtakov
<akurt...@redhat.com> wrote:
On Thu, Apr 7, 2022 at 9:30 AM Aleksandar Kurtakov
<akurt...@redhat.com> wrote:
On Thu, Apr 7, 2022 at 8:34 AM Ed Merks
<ed.me...@gmail.com> wrote:
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.
Would that help at least partially address your
current concerns? Or
is there something that's broken even with that
approach?
> Thanks and regards
> Christian
>
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
--
Aleksandar Kurtakov
Red Hat Eclipse Team
--
Aleksandar Kurtakov
Red Hat Eclipse Team
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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@eclipse.org
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@eclipse.org
To unsubscribe from this list,
visithttps://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
