Update JRuby and all JRuby/Maven plugins #263
Conversation
headius
force-pushed
the
update_jruby_and_plugins
branch
from
7f10cf0
to
5dadf0a
Compare
headius
force-pushed
the
update_jruby_and_plugins
branch
from
5dadf0a
to
11d1881
Compare
|
@mosabua I pushed an update to add the Sonatype snapshots repo to pluginRepositories, which should get this build farther. |
This is part of work to update the entire JRuby/Maven stack, in order to update the version of JRuby used and to address API deprecations at rubygems.org. This PR updates JRuby to latest (9.4.3.0) and moves all plugins to their new org.jruby.maven group ID with latest versions. The maven-tools gem is updated to 1.2. Part of the fix for jruby/maven-tools#37. We will need to coordinate getting this released along with the maven plugins in the very near term. Because of the rubygems.org API being shut down next week (the 8th), we are under the gun. See jruby/mavengem#9, jruby/jruby-maven-plugins#126, jruby/maven-tools#38 and jruby/jruby#7872.
headius
force-pushed
the
update_jruby_and_plugins
branch
from
11d1881
to
b10aaad
Compare
|
@mkristian ping |
|
I was just able to do a local rebuild of JRuby with all of the following artifacts updated:
I believe this is close to having everything in the right places. I need to untangle what order to do releases in to make this all work right. If it were possible to get a snapshot drop of polyglot-maven it would definitely aid testing! |
|
you want this PR deployed as snapshot or master of it? |
|
@cstamas Whatever works better for your process! I just can't do the full JRuby CI against all the snapshots until this one is available remotely. |
|
Deployed 0.4.11-SNAPSHOT (this PR): |
|
Word of warning: with maven 3.9.4 the build failed 😞 Is plexus-util added to plugin classpath? (as 3.9 cuts the ties with Maven2 where p-u was "auto injected/added to classpath of a plugin"). |
You are asking if it is in the classpath of the JRuby/Maven plugins, yes? I'll investigate that. I did not change anything related to this. |
|
@cstamas how to to handle p-u if we want this to work with both old and new maven versions ? explicitly adding it to classpath ? |
|
got the problem which is in https://github.com/takari/polyglot-maven/blob/master/polyglot-maven-plugin/pom.xml and adding plexus-utils solve the problem. Not sure why this PR broke it - probably it did not - still double checking . . |
|
Yes, explicitly add p-u to classpath, as any other dependency, 3.9 cut ties with Maven 2.x legacy. Every 3.9.x had this in release notes explaining it: |
|
No, this pr is unrelated. It was me "just to try out" as on my workstation default mvn is 3.9.4. With mvnw it all works, but, may have issues at runtime if used with 3.9.x |
|
Use of p-u version 3.5.1 (not newer like 4.x) recommended |
|
@cstamas this fixed the maven-3.9.4 failure on my side |
|
#264 ----^ |
|
Is it possible that something in your snapshot build is building with Java 20 bytecode? I've got something in the stack that's causing me to get a I will double-check my other JRuby/Maven projects and make sure they've all been build with Java 8 bytecode. |
|
I'll take a look as maybe there's an external snapshot. This repo should be on 8. |
|
It appears that mavengem and jruby-maven-plugins are being deployed with Java 8 compat bytecode. The failure seems to happen during dependency fetching at the beginning of the build. If I wipe out, say, all of Once all dependencies have been fetched then Java 8 works properly. Seems like it would point at my mavengem mojo being the problem but I'm not sure what could be causing it. The failure happens while evaluating the pom.rb files, I believe, which might implicate polyglot-ruby? I'm shooting in the dark right now. The exception is just this, with no cause or further information, and the stack trace just shows some Ruby method being called followed by NoClassDefFound: |
|
I have not found my root problem, but I have isolated it to when the JRuby used by mavengem is allowed to JIT compile Ruby code to JVM bytecode. The error ends up being a LinkageError because two versions of a core JRuby class are being loaded from two different classloaders. I'm working around it for the moment by having mavengem disable the JRuby JIT. I ran into this once before and was told it might be a bug in JDK 8ish. We worked around it at the time, but I can't locate that code at the moment. The fact that this works properly on JDK 11+ makes me believe it is again a JDK bug at least in JDK 8. |
|
I have filed an OpenJDK issue for the LinkageError I'm seeing. I'll proceed with no-JIT mavengem for now. |
|
No, I am wrong. Just figured above where I commented about 3.9.4 not working. I ued wrapper (3.6.3 and Java 8)... |
|
@cstamas @jvanzyl @mkristian @mosabua I have released jruby-maven-plugins 3.0.0 and mavengem 2.0.0 to central and confirmed a local build of JRuby using those two plus an updated local snapshot of polyglot-maven. If you can push an updated snapshot I can run it through CI for additional confirmation, but I think we're in good shape. |
|
Am deploying in few... |
|
Deploy done: |
|
Everything looks good here: jruby/jruby#7872 The few failures are either because I'm not prefetching the polyglot snapshot on that environment (rather than custom settings.xml) or it's an unrelated failure (a few tests went red recently and weren't noticed). I think this is good to release. What else can I do to help? |
|
Just FYI, I had a chat with the rubygems.org folks and the deprecated API that's going away will be available until we say we're ready for them to shut it off. |
|
I cleaned up some of the failures on JRuby master and the PR is greener now. Remaining builds are just not pre-fetching the polyglot snapshot. |
|
Oh hold the presses... I should release a non-pre maven-tools gem and reference that. |
|
Done! The pre1 gem and the released gem are identical, so this doesn't really change anything, but it's better to not depend on the prerelease version. |
|
Is there anything I can do to help get this merged and released? We can't upgrade to the new JRuby Maven stack until we can pull in updated polyglot. |
Incidentally, if there's anything we might do better to isolate polyglot and its dependencies from mavengem/jruby-maven-plugins used by the build, I'd love to help make that happen. As it is now, there are challenges running a polyglot with older JRuby than the Maven plugins actually activated during the build, meaning they all must update JRuby in lockstep. |
|
I can merge, but am currently away from home and have no access to linux box I usually do releases from (home around 24th Aug). If this is not acceptable for you guys, please ask someone else to perform release. |
|
@cstamas Next week is fine! |
Some of the .0 artifacts still had references to de.saumya and org.torquebox versions, so all three projects have been updated to the latest releases and re-released. No functional changes, for the most part, since the libraries themselves were already using the new artifacts. This mostly affects tests and documentation and gets rid of all the old artifact references.
|
One more push to update all of the JRuby/Maven dependencies. Some of them still used older artifacts out of necessity (self-referential or circular-referential dependencies) and some of the documentation still referenced those older artifacts. All are now updated to latest. |
|
Am back, so are we fine? Merge and release? |
|
Make it so! |
|
FYI the release report https://sbom.sonatype.com/report/T1-118f0f57da8c6b3097cc-546c0fefd37fe5-1692990042-c93b35e844a54bfea7042f0290a354db @mkristian I forgot that p-u is affected by it 😞 |
|
0.4.11 landed in Maven Central, enjoy! |
|
Excellent! I will merge support into JRuby and we should be good. |
|
What can be done to improve this ?
|
|
I have an old, long ongoing PR that I will probably split into multiple smaller ones, that among others sorts out the plexus-utils stuff, migrates from plexus to JSR330 but there are some issues as well (in kotlin), hence will split it to make these baby steps... Also, there is parent POM update, that in turn means move to takari-lifecycle 2.x line, and it has some issues i want to sort out, among others, takari-lifecycle became Java 11, so would raise buildtime Java requirement to 11, but could still happily produce Java 8 artifacts.... so, please chime in there and possibly comment about these |
|
@mkristian if you are asking in general what could be done to improve this, I would say better isolation of the JRuby used for polyglot from any JRuby used in Maven plugins like mavengem. The only reason I needed to update polyglot at the same time was because its older jruby caused problems when the plugins needed a newer one. |
|
@cstamas continuing to support Java 8 in built artifacts would be great because we will continue to support Java 8 for at least another year. |
This is part of work to update the entire JRuby/Maven stack, in order to update the version of JRuby used and to address API deprecations at rubygems.org.
This PR updates JRuby to latest (9.4.3.0) and moves all plugins to their new org.jruby.maven group ID with latest versions.
Part of the fix for jruby/maven-tools#37. (incorrectly tagged as #37 here before)
We will need to coordinate getting this released along with the maven plugins in the very near term. Because of the rubygems.org API being shut down next week (the 8th), we are under the gun.
See jruby/mavengem#9, jruby/jruby-maven-plugins#126, jruby/maven-tools#38 and jruby/jruby#7872.