Closed wborn closed 1 year ago
Did you already find some time to look into this issue @pfink?
Yes. But I only tried the unleash fork option yet, because I thought it would be the faster fix. I could fix the exception by upgrading the unleash plugin to Weld 3.1.6 which is possible with a small change in the source code. Anyhow, the next exception is coming:
[ERROR] Failed to execute goal com.itemis.maven.plugins:unleash-maven-plugin:2.10.1-SNAPSHOT:perform (default-cli) on project org.openhab.core.reactor: Execution default-cli of goal com.itemis.maven.plugins:unleash-maven-plugin:2.10.1-SNAPSHOT:perform failed: Unable to make protected final java.lang.Class java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int) throws java.lang.ClassFormatError accessible: module java.base does not "opens java.lang" to unnamed module @6ad6ae45 -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal com.itemis.maven.plugins:unleash-maven-plugin:2.10.1-SNAPSHOT:perform (default-cli) on project org.openhab.core.reactor: Execution default-cli of goal com.itemis.maven.plugins:unleash-maven-plugin:2.10.1-SNAPSHOT:perform failed: Unable to make protected final java.lang.Class java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int) throws java.lang.ClassFormatError accessible: module java.base does not "opens java.lang" to unnamed module @6ad6ae45
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:215)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
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:128)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
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:957)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)
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)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution default-cli of goal com.itemis.maven.plugins:unleash-maven-plugin:2.10.1-SNAPSHOT:perform failed: Unable to make protected final java.lang.Class java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int) throws java.lang.ClassFormatError accessible: module java.base does not "opens java.lang" to unnamed module @6ad6ae45
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:148)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:210)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
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:128)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
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:957)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)
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)
Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make protected final java.lang.Class java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int) throws java.lang.ClassFormatError accessible: module java.base does not "opens java.lang" to unnamed module @6ad6ae45
at java.lang.reflect.AccessibleObject.checkCanSetAccessible (AccessibleObject.java:354)
at java.lang.reflect.AccessibleObject.checkCanSetAccessible (AccessibleObject.java:297)
at java.lang.reflect.Method.checkCanSetAccessible (Method.java:199)
at java.lang.reflect.Method.setAccessible (Method.java:193)
at org.jboss.weld.util.bytecode.ClassFileUtils$1.run (ClassFileUtils.java:67)
at java.security.AccessController.doPrivileged (AccessController.java:569)
at org.jboss.weld.util.bytecode.ClassFileUtils.makeClassLoaderMethodsAccessible (ClassFileUtils.java:60)
at org.jboss.weld.bootstrap.WeldStartup.startContainer (WeldStartup.java:220)
at org.jboss.weld.bootstrap.WeldBootstrap.startContainer (WeldBootstrap.java:72)
at org.jboss.weld.environment.se.Weld.initialize (Weld.java:808)
at com.itemis.maven.plugins.cdi.AbstractCDIMojo.execute (AbstractCDIMojo.java:196)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:137)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:210)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
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:128)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
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:957)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)
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)
Couldn't have a closer look into this one yet.
Probably, using the maven release plugin would be the better option for the long-term, but for now I guess it would also require significant efforts.
Another idea could be to run the build step with Java 17, and the unleash steps with Java 11 as a fast fix to get the pipeline running again. This could give us some time for migrating to the maven release plugin.
Thanks for looking into this!
Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make protected final java.lang.Class java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int) throws java.lang.ClassFormatError accessible: module java.base does not "opens java.lang" to unnamed module @6ad6ae45
That looks like WELD-2620 which might be fixed in even newer Weld versions.
You could also try to work around it by opening the package using some additional MAVEN_OPTS:
MAVEN_OPTS=--add-opens java.base/java.lang=ALL-UNNAMED
Thanks! I'm on travel until Friday, will give it a try on the weekend.
MAVEN_OPTS=--add-opens java.base/java.lang=ALL-UNNAMED
Thanks, with this it seems to run fine now, even though I didn't test the whole release chain. Newer Weld versions bring more issues, 3.1.6 is the last one which does work without further fixes - that's why I tried this option first to get a quick fix.
Remark: It'll fail with Maven versions older than 3.8.3 because they contain CDI API 1.0 which conflicts with 2.0 required by Weld 3. As of 3.8.3, Maven does only contain the Inject API.
I pushed my changes to my own forks already, so how do we continue? I don't have the permissions to fork the projects to openHAB and I'm not sure if the openHAB project wants to maintain it. I could either keep it in my own repo and publish it to Maven Central, or we move it to the openHAB project and set me as a maintainer, both would be fine for me.
These would be the projects to fork:
https://github.com/shillner/unleash-maven-plugin https://github.com/shillner/unleash-scm-provider-git https://github.com/shillner/maven-cdi-plugin-utils
I pushed my changes to my own forks already, so how do we continue?
Hey @pfink, glad to hear that you made progress on this! I don't really have any preference here - both options sound fine to me. As the changes are not specific to openHAB in any way, I'd think it is just fine if you do the changes in your own fork and publish the result to Maven Central for openHAB to consume. If you prefer to maintain it under the openhab org on Github, I'll also be happy to grant you the according rights, so up to you.
@pfink Any update here? We have reached February and it would be time for a first milestone release of openHAB 4...
@pfink Would be great to get an update from you!
So we missed one milestone completely due to this issue, what a pitty☹️ @pfink Can we have an update please….
I'm sorry for the delay due to me, I was ill the last weeks :( Will continue asap on this.
Sorry to hear @pfink !!! Hope it was not too serious and you are feeling better now.
We have reached February and it would be time for a first milestone release of openHAB 4
To prevent compatibility issues between milestones the Karaf upgrade PRs (#1446) also need to be merged before the first milestone can be made.
Update: On the upcoming weekend, there will be siginificant progress on this, I'm working on it.
I think the new plugin version should be ready now, but it's a bit hard to test the whole pipeline right now because there are already one or more unrelated issues that were introduced due to the changes in OH4. Anyhow, I don't want to go through the whole process of releasing the plugin before knowing that there are no remaining issues with it.
So I tried the quick-fix I suggested earlier
Another idea could be to run the build step with Java 17, and the unleash steps with Java 11 as a fast fix to get the pipeline running again.
and it seems to work completely fine with that: https://ci.openhab.org/view/Sandbox/job/sandbox-openhab4-release/ (pipeline just fails due to an unrelated issue mentioned below)
4 PRs / issues I opened:
Let's use this issue (#1445) as a wrapper thread to get the pipeline green now and aggregating TODOs for that. Currently, the following issues / PRs are on the critical path:
The pipeline is succeeding again! 🥳 Now we can start planning the first milestone build.
Hooray! 🎉 Many thanks, @pfink - great work!
It does not seem to be fully stable yet, though, see https://ci.openhab.org/job/sandbox-openhab4-release/850/ This failed on Z-Wave, while there wasn't any change in the repo and the SNAPSHOT references should have been replaced by the pipeline:
[ERROR] 08:19:29,872 The following modules have references to SNAPSHOT parents that are not scheduled for release:
[ERROR] 08:19:29,872 org.openhab.addons.bundles:org.openhab.binding.zwave:4.0.0-SNAPSHOT => org.openhab.addons:org.openhab.addons.reactor:4.0.0-SNAPSHOT
[ERROR] An exception was caught while processing the workflow step with id 'checkParentVersions'.
The sandbox-openhab3-patch-release was running concurrently. I don't know if both jobs cleanup/deploy to the same Maven repos causing issues? I've launched another OH4 sandbox build without an OH3 sandbox build running.
That might indeed be a reason - let's see if the new job succeeds and we can close this issue again.
Zwave succedded ;-)
I don't know if both jobs cleanup/deploy to the same Maven repos causing issues?
Definitely that's the issue. The whole repo is deleted when a sandbox release jobs start, that's why they can't run concurrently. I installed and configured the Throttle Concurrent Builds Plugin to prevent this in the future.
Just to document what I did:
sandbox-release
in Jenkins System Configuration and set Total Number of Concurrent Builds of this category to 1
I think it should work, but I didn't want to test right now because I don't want to risk breaking the running build.
Indeed, it all looks good - thanks so much!
The release pipeline job uses the unleash-maven-plugin which is not compatible with Java 17 (see also #1444).
It logs the following error in the sandbox-openhab4-release job:
[ERROR] Failed to execute goal com.itemis.maven.plugins:unleash-maven-plugin:2.9.3:perform (default-cli) on project org.openhab.core.reactor: Execution default-cli of goal com.itemis.maven.plugins:unleash-maven-plugin:2.9.3:perform failed: WELD-001524: Unable to load proxy class for bean Implicit Bean [javax.enterprise.event.Event] with qualifiers [@Default] with class interface javax.enterprise.event.Event using classloader ClassRealm[plugin>com.itemis.maven.plugins:unleash-maven-plugin:2.9.3, parent: jdk.internal.loader.ClassLoaders$AppClassLoader@5cb0d902]: Could not initialize class org.jboss.classfilewriter.ClassFile -> [Help 1]
The unleash-maven-plugin is no longer maintained so if we want to keep using it we would need to:
The other alternative is to replace the unleash-maven-plugin with the maven-release-plugin but that could increase release times and be more error prone.
It will be difficult to make milestone/final releases without a working release pipeline.