search

openhab / openhab-distro

The binary distribution of openHAB
https://www.openhab.org/
Eclipse Public License 2.0
1.3k stars 394 forks source link

Release pipeline does not work with Java 17 #1445

Closed wborn closed 1 year ago

wborn commented 1 year ago

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.

wborn commented 1 year ago

Did you already find some time to look into this issue @pfink?

pfink commented 1 year ago

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.

pfink commented 1 year ago

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.

wborn commented 1 year ago

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

pfink commented 1 year ago

Thanks! I'm on travel until Friday, will give it a try on the weekend.

pfink commented 1 year ago

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

kaikreuzer commented 1 year ago

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.

kaikreuzer commented 1 year ago

@pfink Any update here? We have reached February and it would be time for a first milestone release of openHAB 4...

kaikreuzer commented 1 year ago

@pfink Would be great to get an update from you!

hmerk commented 1 year ago

So we missed one milestone completely due to this issue, what a pitty☹️ @pfink Can we have an update please….

pfink commented 1 year ago

I'm sorry for the delay due to me, I was ill the last weeks :( Will continue asap on this.

hmerk commented 1 year ago

Sorry to hear @pfink !!! Hope it was not too serious and you are feeling better now.

wborn commented 1 year ago

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.

pfink commented 1 year ago

Update: On the upcoming weekend, there will be siginificant progress on this, I'm working on it.

pfink commented 1 year ago

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:

wborn commented 1 year ago

The pipeline is succeeding again! 🥳 Now we can start planning the first milestone build.

kaikreuzer commented 1 year ago

Hooray! 🎉 Many thanks, @pfink - great work!

kaikreuzer commented 1 year ago

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'.
wborn commented 1 year ago

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.

kaikreuzer commented 1 year ago

That might indeed be a reason - let's see if the new job succeeds and we can close this issue again.

hmerk commented 1 year ago

Zwave succedded ;-)

pfink commented 1 year ago

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:

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.

kaikreuzer commented 1 year ago

Indeed, it all looks good - thanks so much!