Migrate from Sonatype's OSSRH to Sonatype's Central Repository Portal

[kwwall]

Rationale

• Sonaytype has declared the Open Source Software Repository Housing (OSSRH) as end-of-life on 2025-06-30.
• OSS projects are encouraged to migrate before this date to Sonatype's Central Portal, otherwise one may lose the ability to publish.
• Doing this migration supposedly is difficult (for possibly synchronization reasons) for projects sharing a common name space. Since many OWASP projects share the org.owasp namespace, Jeremy Long had opened a ticket with Sonatype Central Support and requested that temporary dual-publishing for org.owasp and its child namespaces be allowed during the interval.

Important Links

Referenced by Sonatype in Their Notification Email

• Instructions for self migration are located here: https://central.sonatype.org/faq/what-is-different-between-central-portal-and-legacy-ossrh/#self-service-migration

Relevant Links Discovered by ESAPI Team

• https://central.sonatype.org/publish/publish-maven/#deploying-to-ossrh-with-apache-maven
• https://central.sonatype.org/publish/publish-maven/#gpg-signed-components
• https://central.sonatype.org/publish/publish-portal-guide/
• https://central.sonatype.org/publish/publish-portal-maven/
• https://central.sonatype.org/publish/publish-maven/

Other

This will likely affect the following:

• ESAPI's pom.xml
• ESAPI developers' (at least those who can upload to Maven Central repos) $HOME/.m2/settings.xml
• The ESAPI Release Steps (documentation/ESAPI-release-steps.odt, documentation/ESAPI-release-steps.pdf)

[jeremiahjstacey]

Starting to look into this update. I am able to authenticate to the new site.

Next steps will be reviewing links from task description to evaluate how to move forward.

Will likely need to stage a release candidate locally so that I have viable content to attempt to publish. Will review other discussions to bring that process/conversation into this thread.

[kwwall]

@jeremiahjstacey ,

You wrote:

Will likely need to stage a release candidate locally so that I have viable content to attempt to publish. Will review other discussions to bring that process/conversation into this thread.

​In the distant past, I just did a really simple release candidate named RC1 that was limited to changes to the pom. That makes the PR and testing trivial.

[jeremiahjstacey]

TODO: Correct documentation esapi-release-steps.pdf for sending keys. the - - send keys is showing a single dash rather than two. Didn't work with copy/paste and took a minute to figure out.

I don't have an appropriate editor for the document type right now

# Current pdf content:
 $ gpg --keyserver hkp://pool.sks-keyserver.net –send-keys 8A2A524F
## Should be this (note the dashes on send-keys)
 $ gpg --keyserver hkp://pool.sks-keyserver.net --send-keys 8A2A524F

[jeremiahjstacey]

TODO: Discuss documentation updates for setting version with maven commands:

 3.1.3 Update the ESAPI pom.xml for the 2.x.y.z release
 Edit the pom.xml, as appropriate. Minimally, you will want remove the '-SNAPSHOT' from the 
<version>, possibly replacing it with '-RC#' if you are just releasing a “release candidate” or just 
deleting the '-SNAPSNOT' altogether if this is to be an official release.
    $ gvim pom.xml
    $ git add pom.xml
 # Or whatever your favorite text editor is
    $ git commit -m “Bump release to new release number.” pom.xml

gvim is not needed:

 3.1.3 Update the ESAPI pom.xml for the 2.x.y.z release
 Update the artifact version Minimally, you will want remove the '-SNAPSHOT' from the 
<version>, possibly replacing it with '-RC#' if you are just releasing a “release candidate” or just 
deleting the '-SNAPSNOT' altogether if this is to be an official release.
    $ mvn versions:set -DnewVersion=2.x.y.z
    $ mvn versions:commit  #This cleans up rollback artifacts generated from the previous call
    $ git add pom.xml
    $ git commit -m “Bump release to new release number.” pom.xml

If we continue using gvim, comment should be moved to a postfixed inline comment:

 3.1.3 Update the ESAPI pom.xml for the 2.x.y.z release
 Edit the pom.xml, as appropriate. Minimally, you will want remove the '-SNAPSHOT' from the 
<version>, possibly replacing it with '-RC#' if you are just releasing a “release candidate” or just 
deleting the '-SNAPSNOT' altogether if this is to be an official release.
    $ gvim pom.xml   # Or whatever your favorite text editor is
    $ git add pom.xml
    $ git commit -m “Bump release to new release number.” pom.xml

[kwwall]

@jeremiahjstacey: That comment

 # Or whatever your favorite text editor is

was meant to apply to the previous editing step of pom.xml. It should have looked like:

$ gvim pom.xml     # Or whatever your favorite text editor is
$ git add pom.xml
$ git commit -m “Bump release to new release number.” pom.xml

[jeremiahjstacey]

@kwwall I'm tracking, but by using the mvn versions:set command eliminates the need for an editor.
It updates the versions in the pom without needing to open the file.

It's an alternative approach and may lead toward additional scripting utility, if desired.

[jeremiahjstacey]

Additional content
3.1.2 Create release notes for the 2.x.y.z release

1. Instructions do not qualify to also commit the generated scripts/vars.2.x.y.z file created from the execution of the createVarsFiles.sh.
2. (Optional Addition) From windows, Gitbash includes a dos2Unix.exe that can be used to account for the line ending concerns.

[jeremiahjstacey]

I'm doing a poor job on release notes for this test. I believe the only real change is a property name that slipped through last release.
I did find a possibly useful git command to diff tags:
git diff esapi-2.7.0.0 esapi-2.7.1.0-RC1

I think that in the workflow we may be able to use the "compare my current with a tag" to help review the release content.
If I'm understanding the workflow correctly:

1. Create the new branch as defined in 3 Steps for each new ESAPI 2.x.y.z release
2. Once on the new branch, run git diff last-release-tag to help prep for the release notes.
   • I'm not sure if this is needed, but thought it may be potentially useful and worth mentioning