-
Notifications
You must be signed in to change notification settings - Fork 594
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Nexus-Staging-Maven-Plugin illegal reflective access through XStream usage #110
Comments
Another update: The problem during rc-release does not occur with XStream 1.4.15, but on 1.4.18 which I had upgraded to before performing the release. I have not investigated why the more recent version breaks the release action or which XStream release 1.4.16 to .18 actually broke it. I just know that with 1.4.15 it works nicely without any --add-opens statements. |
Hi @lprimak - thanks for opening this issue as well. As I mentioned in #109, this issue appears to be related to the nexus-staging-maven-plugin. We appreciate your input and suggestions on this topic. Development effort for running the plugin on more contemporary JDKs is not something at present in our short term plans. I'll discuss internally with the team and report back. |
I am going to attach a couple of issues all related to this problem, exported from Jira. Sorry for the noise, but I think it is important to retain the issues incl. comments.
The current LTS version in Java 17 with next LTS Java 21 around the corner. Java 11 is no longer the current LTS version. How can this not have been in your short-term plan for a long time already? The impact is huge! Everyone deploying to Maven Central needs this. Are you really expecting everyone to build on Java 11 because of Sonatype? |
NEXUS-26993, click to expand/collapse.
Description
Comments
Generated at Mon May 15 05:51:34 UTC 2023 by Alexander Kriegisch using NEXUS-31301, click to expand/collapse.
Description
Comments
Generated at Mon May 15 05:52:45 UTC 2023 by Alexander Kriegisch using NEXUS-27902, click to expand/collapse.
Description
Comments
Generated at Mon May 15 05:53:22 UTC 2023 by Alexander Kriegisch using NEXUS-31214, click to expand/collapse.
Description
Comments
Generated at Mon May 15 06:20:20 UTC 2023 by Alexander Kriegisch using |
Just FYI due to this and many other reasons I stopped using the staging plugin. |
@lprimak, while this is nice, it also requires infrastructure, e.g. on Windows probably something like Git Bash. Usually, this is not what my IDE uses. Furthermore, even though this approach might work, it speaks volumes that Maven Central users start creating shell scripts using curl, because they cannot use the Maven plugin produced by the same company producing Nexus, which is used to host Maven Central. |
NO ONE NEEDS THIS PLUGIN, SERIOUSLY. The regular Maven Deploy Plugin does the required job. |
@michael-o, of course the plugin is not needed for the deployment as such. But it facilitates closing and releasing the staging repository as well, which I like as a feature. I do not like to either call curl or log into the Nexus GUI in order to do so. The nice thing about this plugin is that it enables users to do everything from within Maven. I use it for all my OSS projects. Therefore, I am pushing this issue. Nexus Staging Maven Plugin's right to exist - adding the value I described above - should be justified by making it work on current JDKs. |
So what you rather need is a post-deploy close and release process, right? |
Sure, @michael-o. This is also described in the issues I linked to. E.g., expand NEXUS-31214 from my post above and scroll to the end of the description. There you will see that it is e.g. about the |
Though, I still don't understand why it is so hard to log in into Nexus UI and perform these two steps... |
@michael-o the whole point of automation is to automate the whole process. I want a complete release in one click and one UI is Jenkins is it for me. I don’t want to log into Jenkins and then check if it built and wait and then log onto nexus then find the appropriate repo then more clicks. You see where I am going? :) |
Yes, but the example was Maven Central and for that, I consider it irrelevant, IMHO. Since you have Nexus Pro with staging capabalilites, I guess you should reach out to support, no? |
No I have an OSS project in central. I still want to automate it just the same. |
It is not hard, just tedious and requiring extra manual steps, which kind of defeats the idea of an automated build pipeline or at least a build tool called from the console or an IDE. That you of all people don't get that as someone contributing to so many Maven plugins, is a mystery to me. It is not hard to call javac or javadoc or a jar tool from the console either. So why use Maven in the first place? 😉 |
If I'd get paid to use |
Is that so? Then, good for you. As for myself: Firstly, I don't get paid for OSS development. Secondly, even if that was the case, I would try to automate, automate, automate, because that is what smart developers do and get paid for. Remember the "e" words, efficiency and effectiveness? Last but not least, I don't believe what you just wrote, and I would be very surprised if you believed it yourself. You are far too smart and hardly jaded enough to make your own life as a developer more complicated than necessary, even if someone would pay you to be a stupid robot. It would just not be you, Michael. |
Also the person authorized to kick off releases may not be authorized for the sonatype UI, so sharing credentials could be a big barrier. |
I've invited @kishlaynikesh, a Product Manager for the Maven Central Publisher experience, to comment on the future for publishing to Maven Central. |
thank oyou! |
From Maven Central standpoint, nexus-staging-maven-plugin will not be needed once the new publisher staging workflow is made available by early July timeframe. However, it can still be used by a Nxrm2 user locally, but not useful for anything central publishing related. Hope this helps with better clarity. |
Thanks for the info. |
@kishlaynikesh: Actually, no. I understand that the Maven plugin will no longer be needed, but you did not give any description of how else I would be able to perform steps of the staging workflow from Maven (other users might be more interested in Gradle, but I am being egoistic here, focusing on Maven). A sneak peek would be helpful, just like @lprimak said. |
High level change summary: User Migration to new workflow: |
Thanks! So the question becomes "is the current NXRM rest service going away?" What is the new maven plugin going to look like? i.e. can I release a all open repos belonging to a profile? |
@lprimak Nexus Repository 2 instance(used for content publishing on Maven Central) is to be decommissioned. The new publisher interface isn’t going to be a Nexus Repository instance. Regarding the requirement “release all open repos belonging to a profile using the new Maven plugin” is under design/development. We can confirm near to the release date if that will also be available with the launch version. |
Thank you @kishlaynikesh and the community for joining in the conversation! So to summarize, Sonatype will be offering new capabilities to publish to Maven Central this year. I intend to close this ticket as "not planned." |
Be sure to let us know (comment on this issue) once the new offering comes out. Thank you. |
@kishlaynikesh @nblair did something change here? The guide at https://central.sonatype.org/publish/publish-maven/ still recommends the staging plugin |
It looks like we dropped the ball on updating this thread. Yes, that link still points to the older form of publishing to maven central. There is a new process that should be leveraged instead. Starting with https://central.sonatype.org/register/central-portal/ to register, then https://central.sonatype.org/publish/publish-portal-maven/ provides documentation on a new plugin to use instead. |
ooh nice - thanks a lot! |
What you call "older" is still the current standard process, if I understand the docs correctly. Given the fact, that I cannot log into the new portal with my Nexus credentials, it also means that I cannot use the future process and new Maven plugin yet without redundantly re-registering, which I will not do. The new way of publishing is also still called "early access", i.e. for now 95% of existing users still have to deal with the Nexus Staging Maven Plugin (or an equivalent Gradle plugin, if any), unless of course they abandon that plugin and use Maven Deploy and then promote the deployed artifacts manually via Nexus. Update: Checking the old issues in #110 (comment) again, it is going on 3 years now that the plugin issues with more recent JDKs have been unresolved. The first of those 4 issues is from 2021-03-10. Add on top the time from early access to general availability of the new process, and you get the picture of customer experience for the developer community using Maven Central. Sorry to complain (again), but this is unacceptable. |
Downgrading xstream within the nexus plugin allowed a release to complete while running Maven on Java SE 21 in Circle CI:
|
For what it's worth, I ended up migrating off nexus-staging-maven-plugin and my headaches went away :) My deployment requirements are more complex than most projects in that I need to upload native binaries from different computers into the same staging environment before cutting a release. The maven-deploy-plugin doesn't handle this out of the box so I had to use Anyone who is interested in doing the same, see https://github.com/cowwoc/requirements.java/blob/master/.github/workflows/deploy_to_maven_central.yml and https://github.com/cowwoc/requirements.java/blob/master/pom.xml. Feel free to ask me any questions that you might have. |
Core Issue
When using the nexus-staging-maven-plugin, an illegal reflective access warning is generated through use of XStream.
Running with MAVEN_OPTS=--illegal-access=debug, the reflective access occurs during XStream initialization. This can be seen here: https://pastebin.com/cHv3G2hM . XStream is aware of the issue and to mitigate it, they have deferred reflective access until absolutely necessary: x-stream/xstream#218 .
Potential Quick Fix
Whether the solution XStream has implemented is sufficient to fix the problem depends on whether the nexus-staging-maven-plugin requires any of the reflective field accesses XStream performs.
As a first start to solve the issue, XStream's version can be updated per this automated PR: sonatype/nexus-maven-plugins#91 It is possible that updating the version of XStream will solve the issue immediately.
Effects on Libraries
When JDK 16 is released this month, illegal reflective access will be denied by default. This presents ramifications to libraries using the nexus-staging-maven-plugin which have a higher JDK build-time requirement even if they are compatible with older JDK versions at runtime. For example, some libraries may want to support record features, and thus require JDK 16.
Changing MAVEN_OPTS=--illegal-access=permit or using .mvn/jvm.config could be a temporary workaround, but at some point this issue will have to be solved. Again, it may be as trivial as incrementing the XStream version.
The text was updated successfully, but these errors were encountered: