On Thu, Apr 7, 2022 at 3:09 PM Christian Dietrich < christian.dietr...@itemis.de> wrote:
> 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 > I see it building orbit-recipes clone. Java version: openjdk version "18" 2022-03-22 OpenJDK Runtime Environment 22.3 (build 18+37) OpenJDK 64-Bit Server VM 22.3 (build 18+37, mixed mode, sharing) Maven version: Apache Maven 3.8.5 (3599d3414f046de2324203b78ddcf9b5e4388aa0) > Am 07.04.22 um 14:02 schrieb Aleksandar Kurtakov: > > > > 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 listcross-project-issues-...@eclipse.org > 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.dietr...@itemis.de > 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 > _______________________________________________ > 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
