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, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
