Sonatype Nexus Repository Issue Tracker is moving

[nblair]

At the end of May 2023, Sonatype will be closing access to our Jira instance at https://issues.sonatype.org/browse/NEXUS.
That instance of Jira has been licensed for Jira Server, a product that is reaching end-of-life with Atlassian on Feb 15, 2024. We expect to complete our internal Issue Tracking transition by the end of May 2023.

As a result, Sonatype will be moving our Issue Tracker for OSS installs of Sonatype Nexus Repository within Github Issues in https://github.com/sonatype/nexus-public as of today, May 1 2023.

Pro customers can continue to use https://support.sonatype.com/. Our support platform will provide continuity for visibility into support tickets that result in internal issues.

If you are a subscriber on an issue in our old Jira instance, expect to see communication pointing here as issues will be closing in the days up to the end of the service.

[nblair]

The first notice on impacted tickets in the https://issues.sonatype.org/browse/NEXUS project was just sent this afternoon. We expect to send an additional notification next week.

Access to https://issues.sonatype.org/browse/NEXUS will be closing on Tuesday, May 23, 2023.

[OmarHawk]

Will you migrate existing open tickets or should "important tickets" be copied manually here?

[kriegaex]

@nblair, I received notifications for 3 Jira issues I am watching, but the important information @OmarHawk also requested is missing from there. I think it is super important to explicitly mention whether existing issues will be migrated to GitHub or not. I very much hope that the answer is yes, because anything less would be an affront to users anxiously waiting for longstanding bugfixes that have been ignored for far too long already.

Look at your wording:

• "closing our Jira instance" → Oh, a service will be discontinued.
• "moving our issue tracker ... to GitHub" → Hm, moving the issue tracker != moving the issues as such.

Maybe you understand how this causes uncertainty in your user base.

P.S.: The issues I am watching are not related to some random OSS install of Nexus but to OSSRH and Maven Central, the most important Nexus instance in the universe. So maybe you kinda understand how this issue here potentially affects a whole lot of users.

[nblair]

@OmarHawk we will not be migrating existing open tickets. I would kindly ask that if you are continuing to experience an issue specifically with Sonatype Nexus Repository OSS, you re-open it here. We do have a set of questions lined up in the new issue template to help us better understand each issue.

@kriegaex it is true that the issue tracker for OSSRH and Maven Central is in the same Jira instance. Those two projects are unaffected by the change occurring on May 23, 2023. They will be moving in the future to a new home prior to February 2024, but the plans are not finalized yet. Another team with Sonatype is working on that transition and will broadcast their plans as they become available.

Definitely appreciate the questions here and happy to help make this as smooth a transition as possible.

[kriegaex]

Sorry to hijack this issue, but now I am even more confused. I received e-mail notifications about 3 NEXUS issues I subscribed to, mentioning that the Jira instance will be closed by the end of this month. Specifically, the issues are all about Nexus Staging Maven Plugin, which is used for releasing stuff to Maven Central and which still has unsolved problems with JDK 16+. So where will I be able to track those issues?

In general, like I said, not migrating the existing issues would be an affront to everyone involved. Information, time and work put into documenting and discussing the issues would be lost. Why anyone would do that, is incomprehensible to me. Sorry for my harsh wording, but this is outrageous. I do not mean to shoot the messenger, so I am not blaming you personally, @nblair.

[ite-klass]

we will not be migrating existing open tickets
[…]
happy to help make this as smooth a transition as possible

With all existing data being discarded, with such a hard break, I don't see how the change could be made anything I'd call smooth. The only thing one can do is general information about that fact and how to handle it.

Does close Jira mean archived (static website?) or disappear?

Could you elaborate your thought process driving the decision to not migrate issues? I think openly communicating your considerations and accepted downsides would help understanding and clarity and consequently how to handle the situation.

If I follow an open issue, would I basically have to manually, for every ticket, summarize the issue and potentially discussion on that ticket in a new ticket here?
Is this the expected workflow for users and issue followers?

[bendem]

That's quite a lot of knowledge and workarounds lost for open issues (1296 tickets with years of context, 104 of those are bugs with more than 1 vote).

It also looks like accounts have been disabled, I'm unable to login to search for the issues I voted on.

[kriegaex]

It also looks like accounts have been disabled, I'm unable to login to search for the issues I voted on.

@bendem, I cannot confirm that. I am presently still able to log in.

[flitzie]

1. Go to Jira ticket -> Export -> Printable -> Save page as txt
2. Got to GitHub -> New Issue -> paste in text

[flitzie]

As a result, Sonatype will be moving our Issue Tracker for OSS installs of Sonatype Nexus Repository within Github Issues in https://github.com/sonatype/nexus-public as of today, May 1 2023.

Pro customers can continue to use https://support.sonatype.com/. Our support platform will provide continuity for visibility into support tickets that result in internal issues.

@nblair
Why don't you track all OSS feature here in GitHub and all Pro features under support (https://support.sonatype.com/)?
Otherwise OSS features are then tracked and discussed in multiple tracking systems.

[kriegaex]

@flitzie, thanks. Unfortunately, Saving to TXT is not an available option in my browser. It would not look good either.

I achieved fairly good results with this approach:

• Jira: Export → Printable → Save as HTML
• Using a local Pandoc installation: pandoc -t gfm -s NEXUS-26993.html -o NEXUS-26993.md, where "gfm" means GitHub-flavoured markdown
• Copy & paste markdown into a GitHub issue description or comment after optionally having edited the markdown document first, if you want to get rid of non-essential parts like Jira header/footer information.

@nblair, doesn't that cry for automation? 😉

---

Here is an example, click to expand/collapse.

[NEXUS-26993] Nexus-Staging-Maven-Plugin illegal reflective access through XStream usage Created: 03/10/21  Updated: 05/10/23
Status:	New
Project:	Sonatype Nexus Repository
Component/s:	staging-maven-plugin
Affects Version/s:	None
Fix Version/s:	None

Type:	Bug	Priority:	Major
Reporter:	Anand Beh	Assignee:	Unassigned
Resolution:	Unresolved	Votes:	11
Labels:	lhf, migration-announce, triaged
Remaining Estimate:	Not Specified
Time Spent:	Not Specified
Original Estimate:	Not Specified
Environment:	Mac OS 10.14.6 OpenJDK Zulu15.28+51-CA (build 15.0.1+9) Apache Maven 3.6.3 Nexus-Staging-Maven-Plugin 1.6.8

Issue Links:	Duplicate Relates relates NEXUS-31214 Problems in Nexus Staging Maven Plugi... Closed relates NEXUS-31211 Version 1.6.9 triggers exception: "co... Closed is related to NEXUS-34850 Regression: rc-drop outputs a SEVERE ... New
Last Updated By:	Nicholas Blair
Date of First Response:	19/Mar/21 3:32 PM

Description

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.

Comments

Comment by Udo Höfel [ 03/19/21 ]

I ran into exactly this problem. Changing the MAVEN_OPTS did indeed help, but this certainly would be good to get fixed.

Comment by Anand Beh [ 06/27/21 ]

Just a heads-up on the importance of this issue: JDK 17 will very likely remove the workaround with MAVEN_OPTS. Using --illegal-access will do nothing: https://openjdk.java.net/jeps/403 "With this change, it will no longer be possible for end users to use the --illegal-access option to enable access to internal elements of the JDK."

Comment by Diogo Nunes [ 09/25/21 ]

This has become a problem, we can't publish to maven now!

Comment by Juan Jose Fidalgo Moran [ 09/26/21 ]

I can't deploy either to Maven Central using Nexus Staging Maven plugin on Java 17,   [ERROR] Failed to execute goal org.sonatype.plugins:nexus-staging-maven-plugin:1.6.8:deploy (injected-nexus-deploy) on project theicenet-cryptography: Execution injected-nexus-deploy of goal org.sonatype.plugins:nexus-staging-maven-plugin:1.6.8:deploy failed: An API incompatibility was encountered while executing org.sonatype.plugins:nexus-staging-maven-plugin:1.6.8:deploy: java.lang.ExceptionInInitializerError: null Is there any plan to fix the illegal reflective access issue on Java 17?. As far as I'm aware, there is not any valid workaround for Java 17.

Comment by Juan Jose Fidalgo Moran [ 09/26/21 ]

For the time being, until this issue is properly fixed at plugin level, I got Nexus Staging Maven plugin working on Java 17 with the workaround, export MAVEN_OPTS="--add-opens=java.base/java.util=ALL-UNNAMED --add-opens=java.base/java.lang.reflect=ALL-UNNAMED --add-opens=java.base/java.text=ALL-UNNAMED --add-opens=java.desktop/java.awt.font=ALL-UNNAMED"

Comment by Grégory Van den Borre [ 09/26/21 ]

Thank you Juan Jose Fidalgo Moran, i can confirm this workaround make possible to deploy on maven central with java 17

Comment by Alexander Kriegisch [ 09/26/21 ]

I just tried and for me it works like this, without any MAVEN_OPTS: <plugin> <groupId>org.sonatype.plugins</groupId> <artifactId>nexus-staging-maven-plugin</artifactId> <version>1.6.8</version> <extensions>true</extensions> <configuration> <!-- (...) --> </configuration> <dependencies> <!-- TODO: Remove after OSSRH-66257, NEXUS-26993 are fixed, possibly via https://github.com/sonatype/nexus-maven-plugins/pull/91 --> <dependency> <groupId>com.thoughtworks.xstream</groupId> <artifactId>xstream</artifactId> <version>1.4.15</version> </dependency> </dependencies> </plugin>

Comment by Alexander Kriegisch [ 10/08/21 ]

Update for my previous comment: Staging without release is what I tested before and which was working. But a command like mvn nexus-staging:rc-release -DstagingRepositoryId=myId-1234 failed again on JDK 17, so in that case the XStream update is not enough. Here is a console log: $ mvn nexus-staging:rc-release -DstagingRepositoryId=orgaspectj-1112 [INFO] Scanning for projects... [INFO] Inspecting build with total of 1 modules... [INFO] Installing Nexus Staging features: [INFO] ... total of 1 executions of maven-deploy-plugin replaced with nexus-staging-maven-plugin [INFO] [INFO] ------------------< org.aspectj:org.eclipse.jdt.core >------------------ [INFO] Building JDT Core for AspectJ 1.9.8.RC1 [INFO] --------------------------------[ jar ]--------------------------------- [INFO] [INFO] --- nexus-staging-maven-plugin:1.6.8:rc-release (default-cli) @ org.eclipse.jdt.core --- [INFO] + Using server credentials "ossrh" from Maven settings. Security framework of XStream not explicitly initialized, using predefined black list on your own risk. [INFO] * Connected to Nexus at https://oss.sonatype.org:443/, is version 2.14.20-02 and edition "Professional" [INFO] RC-Releasing staging repository with IDs=[orgaspectj-1112] [INFO] ------------------------------------------------------------------------ [INFO] BUILD FAILURE [INFO] ------------------------------------------------------------------------ [INFO] Total time: 6.065 s [INFO] Finished at: 2021-10-08T09:44:39+02:00 [INFO] ------------------------------------------------------------------------ [ERROR] Failed to execute goal org.sonatype.plugins:nexus-staging-maven-plugin:1.6.8:rc-release (default-cli) on project org.eclipse.jdt.core: Execution default-cli of goal org.sonatype.plugins:nexus-staging-maven-plugin:1.6.8:rc-release failed: No converter available [ERROR] ---- Debugging information ---- [ERROR] message : No converter available [ERROR] type : java.util.Arrays$ArrayList [ERROR] converter : com.thoughtworks.xstream.converters.reflection.ReflectionConverter [ERROR] message[1] : Unable to make field protected transient int java.util.AbstractList.modCount accessible: module java.base does not "opens java.util" to unnamed module @6a638c79 [ERROR] ------------------------------- Looking at the error message part that says module java.base does not "opens java.util" to unnamed module @6a638c79, it looks as if despite the XStream version bump we still need to manually open modules. Please get this fixed ASAP. Thank you.

Comment by Alexander Kriegisch [ 10/20/21 ]

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. Will anyone ever fix this problem? The fix is overdue, really. This is a major problem, not a minor one. It affects all users building on JDK 16+.

Comment by Laird Nelson [ 11/12/21 ]

Can confirm on JDK 17 that this is a problem, and that upgrading xstream to exactly 1.4.15 (a now-outdated version itself!) solves the issue. Upgrading xstream beyond this version causes this issue to fail again.

Comment by Alexander Kriegisch [ 11/26/21 ]

Despite XStream 1.4.15, suddenly I am having problems again when not using --add-opens for MAVEN_OPTS as described in this comment. I do not know why it worked before. Maybe I had forgotten to remove the custom Maven options before testing. This issue still needs to be fixed, and it was open for way too long.

Comment by Lenny Primak [ 11/26/21 ]

Agreed. This is a serious issue and needs to be fixed

Comment by Alexander Kriegisch [ 02/03/22 ]

It has been almost a year since this serious issue has been raised, and it does not even have an assignee yet, not to mention meaningful feedback. Pretty please, Sonatype. Java 16 introduced the problem, Java 17 has been around for a while and as LTS is here to stay. Java 18 is due next month, AFAIR.

Comment by Gili Tzabari [ 02/12/22 ]

This issue should be fixed by sonatype/nexus-maven-plugins#91

Comment by Alexander Kriegisch [ 02/13/22 ]

No, it is not. Plugin version 1.6.9 is completely broken, worse than 1.6.8.

Comment by Lenny Primak [ 02/14/22 ]

1.6.10 is also completely broken.  While releasing using maven release plugin: [ERROR] Failed to execute goal org.sonatype.plugins:nexus-staging-maven-plugin:1.6.10:deploy (injected-nexus-deploy) on project flowlogix: Execution injected-nexus-deploy of goal org.sonatype.plugins:nexus-staging-maven-plugin:1.6.10:deploy failed: Nexus connection problem to URL [ https://oss.sonatype.org/ ]: XPP3 pull parser library not present. Specify another driver. For example: new XStream(new DomDriver()): org.xmlpull.mxp1.MXParser -> [Help 1]

Comment by Alexander Kriegisch [ 02/14/22 ]

Yes, I created NEXUS-31214 for it. It would be funny, if it was not so sad: 1.6.8 did not work ever since JDK 16 was released 11 months ago, but at least could be tricked into working with additional plugin dependencies and JVM options. 1.6.9 could deploy (with errors), but not release. 1.6.10 does not work at all, I cannot even do a simple rc-list. It seems as if each release makes matters worse rather than better. Instead of burning release numbers, a little bit of basic pre-release testing would be helpful. Assuming that an integration test suite actually does exist, maybe someone just accidentally built with `-DskipTests`. Shit happens, no problem. We are all human, after all. But please, fix it ASAP. Thank you so much.

Comment by Garret Wilson [ 02/14/22 ]

Could someone give me a summary of what plugin we are supposed to be using? In a GitHub pull request, someone alluded to some newer plugin? You are probably aware of how different staging is for Nexus Repository Manager 3 … I'm running into all these staging errors that everyone else is with Java 17. But is there a newer staging plugin we should be using, and which doesn't have all these bugs? If so, I'll be happy to switch to it. Where is the official documentation about the preferred plugin, and how to migrate from the old plugin? Because surely Sonatype wouldn't be letting this plugin just sit here for months breaking with the latest LTS Java version if this is the preferred plugin to use, would they?

Comment by Gili Tzabari [ 02/14/22 ]

Garret, My understanding is that Maven Central runs Nexus v2 whereas commercial customers use Nexus v3. https://github.com/sonatype/nexus-maven-plugins/ is designed for Nexus v2 so this is the correct plugin to use.

Comment by Garret Wilson [ 02/14/22 ]

Gili, thanks for clarifying. Wow, speechless that they would leave us in the lurch like this. And Maven is one of the cornerstones of modern artifact deployment. Incredible.

Comment by Lenny Primak [ 02/26/22 ]

1.6.12 version of the plugins is working for me now. I have successfully released a module with it

Comment by Alexander Kriegisch [ 04/01/22 ]

A month ago Nicholas Blair said in this comment: Upgrading xstream and guava will be addressed in the next release of the plugin, expected within the next 2 weeks. I'm going to close this issue, NEXUS-31301 and NEXUS-26993 will be open to track those efforts.{quote} So may I ask where we are with this and how much longer people deploying to OSSRH and releasing to Maven Central will need to switch to outdated Java versions after their builds and use special Java options just to deploy? This is a big issue, not some small detail or corner case. This affects everyone who wants to deploy to OSSRH, the biggest and most important Maven repository on this planet.

Comment by Gili Tzabari [ 08/17/22 ]

Does version 1.6.13 fix this issue? It seems to work for me.

Comment by Gili Tzabari [ 08/17/22 ]

I stand corrected. Per https://issues.sonatype.org/browse/NEXUS-31214?focusedCommentId=1193423&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-1193423 we still get the following error: [ERROR] Failed to execute goal org.sonatype.plugins:nexus-staging-maven-plugin:1.6.13:rc-release (default-cli) on project aspectj-maven-plugin: Execution default-cli of goal org.sonatype.plugins:nexus-staging-maven-plugin:1.6.13:rc-release failed: No converter available [ERROR] ---- Debugging information ---- [ERROR] message : No converter available [ERROR] type : java.util.Arrays$ArrayList [ERROR] converter : com.thoughtworks.xstream.converters.reflection.ReflectionConverter [ERROR] message[1] : Unable to make field protected transient int java.util.AbstractList.modCount accessible: module java.base does not "opens java.util" to unnamed module @2924f1d8 Can someone from Sonatype please update us on the status of this ticket?

Comment by Stefano Cordio [ 08/17/22 ]

1.6.13 seems to work properly with Java 17 (originally from NEXUS-27902)

Comment by Alexander Kriegisch [ 08/17/22 ]

No, it does not work properly, like I said in this NEXUS-31214 comment already. Quoting myself: Without MAVEN_OPTS=--add-opens=java.base/java.util=ALL-UNNAMED, I get the good old: [ERROR] Failed to execute goal org.sonatype.plugins:nexus-staging-maven-plugin:1.6.13:rc-release (default-cli) on project aspectj-maven-plugin: Execution default-cli of goal org.sonatype.plugins:nexus-staging-maven-plugin:1.6.13:rc-release failed: No converter available [ERROR] ---- Debugging information ---- [ERROR] message : No converter available [ERROR] type : java.util.Arrays$ArrayList [ERROR] converter : com.thoughtworks.xstream.converters.reflection.ReflectionConverter [ERROR] message[1] : Unable to make field protected transient int java.util.AbstractList.modCount accessible: module java.base does not "opens java.util" to unnamed module @2924f1d8

Comment by Lenny Primak [ 08/17/22 ]

just to clarify what @kriegaex is saying, the plugin does not work for the specific goals of 'rc-release' and it's complement goals release:prepare and release:perform work fine

Comment by Nicholas Blair [ 08/17/22 ]

I've been getting a few notifications on this ticket so I just wanted to chime in and acknowledge the requests. At present this item is not in our planned work in the short term; I'll see where this falls in priority and have our team assess what can be done.

Comment by Gili Tzabari [ 08/22/22 ]

For what it's worth, rc-drop is broken too. I just filed this bug report: https://issues.sonatype.org/browse/NEXUS-34850

Comment by Alexander Kriegisch [ 08/26/22 ]

There are so many related issues already. Do we really need a new one for every single plugin release and every goal? Besides: You can't view this issue It may have been deleted or you don't have permission to view it.

Comment by Joe Tom [X] (Inactive) [ 08/26/22 ]

(I've adjusted 34850 to be public, new tickets default to private on this project in case containing any sensitive information)

Comment by Nicholas Blair [ 05/10/23 ]

Sonatype will retire our public-facing Jira instances on May 25, 2023. This includes https://issues.sonatype.org/browse/NEXUS. The decision is necessitated by a need for increased security as well as to replace a system that is almost at “end of life” with Atlassian. Moving forward, please watch the Release Notes for a list of issues fixed in each product release. Customers with active subscriptions to Sonatype solutions may report defects by raising a support incident at: https://support.sonatype.com. Users of Sonatype Nexus Repository OSS should file issues in: https://github.com/sonatype/nexus-public. Please see #105 for more details.

I did not edit the markdown on purpose, other than removing a minimal amount of header/footer text. I wanted you to see the direct Pandoc result. The remainder would be easy to beautify, but the important thing is that the contents are there. We would, however, have to manually add attachments, if any.

[nblair]

We do appreciate all the input here - I'm glad to see we are able to connect here, it's a good sign this forum is working!

I want to dispel the myth that all of those tickets are being discarded or archived. In fact, that the opposite is true - all of the issues in the NEXUS project are being imported into our new internal issue tracker.

When the new internal issue tracker is private, and accessible to Sonatype employees only - unfortunately the community will not be able to see any updates.

The experience you have with our current Jira instance was made possible by a special type of license that Sonatype was able to negotiate with Atlassian long ago. That type of license is no longer offered in their cloud environments; all new deployments are licensed by user count. The number of non-Sonatype participants outnumbered Sonatype employees by a factor in the hundreds - multiplying any budget line item by that factor is just not possible for most companies, let alone a company of our size. As the new issues are migrated, all non-Sonatype participant identities will be lost, so no outbound email notifications with updates will occur. I apologize for that, and I can only ask that you please watch the Release Notes for a list of issues fixed in each product release.

It's true that some of you got comments for things like the staging plugin; that also is a side effect of us lumping "all things Nexus Repository" into the NEXUS project in Jira. We'll be handling the transitions for those projects separately in the coming weeks.

Appreciate the creativity of the engineering community here, but we'd prefer a fresh start rather than automated script imports. If you have an issue or two that you'd like to move here for visibility, please use our new issue template to get an up to date report on the problem you are experiencing.

Our Pro customers will get a bit of an upgrade after the dust settles on our migration. By being fully private, it will enable us to leverage bi-directional integration with our support ticket management system. New tickets created there that result in escalated product development issues will get automatic updates, all through the ticket management system. We'd ask our Pro customers to use https://support.sonatype.com exclusively.

Thanks again - hoping to provide as much transparency as I can and help us navigate the transition.

[philomory]

@nblair Thank you for the explanation. It's not pleasant, but I'm all too familiar with situations where features that were previously free of charge suddenly grow a monthly per-X fee.

That said, it probably would be worth Sonatype's time to take at least the handful of most upvoted issues from JIRA and migrate them to Github themselves (with or without automation), rather than asking users to do it.

[nblair]

We've just sent the second and final notice as a comment on open issues. We are still on track for the change to occur next week.

We appreciate the community adopting this new forum. We just had our first weekly triage call with the product team, and we've closed or updated a number of tickets with the pending column. There's still more to catch up with, more than we've had time to get through in this first run. We'll commit to reviewing items with that pending label every week on Tuesdays.

I intend to close this issue on Tuesday May 23.

[ite-klass]

You may want to pin this issue for discoverability. (That should be possible?) Even if it's just for a few more days.

[ite-klass]

As a tip for anyone migrating a ticket; you can [archive the ticket webpage on archive.org)(https://web.archive.org/save/) and reference/link it. That way that historic ticket content will be referable/inspectable. I've done so in the ones I created.

[nblair]

Our issue tracker migration is green-lit and activities will commence tomorrow. In the afternoon (eastern) access to our on-premise Jira instance will close.

Thank you for your understanding and willingness to engage here!

[soc]

So, if I wanted to publish a new artifact, where would I do this?

(The documentation links to the discontinued JIRA instance which itself links to this repository.)

[JayStGelais]

@nblair

Not sure if I'm reading this change correctly, as the OSS publishing docs still point to the Jira instance...

If we need to add a user to our project, do we add a GitHub issue here or still use the linked Jira instance?

trying to follow the steps here: https://central.sonatype.org/publish/manage-permissions/

[nblair]

@soc and @JayStGelais - publishing your open source artifacts to Maven Central is unchanged and unaffected by this Jira migration (so far). https://central.sonatype.org/publish/publish-guide/ is still the right place to follow, you'll still be able to access the Jira projects they use at issues.sonatype.org for the next few months.

[soc]

@nblair Thanks!

[iseki0]

@nblair So there's no way to see the old issues? Maybe you(I mean sonatype, not you personal) can provide a readonly archive to save the history? Let the history disappeared is never a good choice.😃

[moisesarrona]

Hi, @nblair
When logging into our Nexus instance, it shows us the following error:
Incorrect username, password or no permission to use the Nexus User Interface.
Try again. Please login before attempting further requests.
Is it due to tracker migration?

My version of nexus is 2.14.5-02

[nblair]

Hi @moisesarrona - no, the error you see is not related to the Issue tracker migration. You'll need to follow up with your organization's Nexus Repository administrator to troubleshoot authenticating to your local instance.

[xiaodizi]

I didn't understand what was suspended and now my account can't be logged in. Clicking sign in is 403 Forbidden. I want to publish a jar of my own.