Page History

...

1. Write access to the DSpace GitHub repository hosted at https://github.com/DSpace/DSpace. (All Committers should already have this, obviously)
2. Write access to the org.dspace groupId in the snapshot and staging repositories hosted at oss.sonatype.org.  If you don't already have this, you will need to:
   
   1. Sign up for a Sonatype JIRA account. This account will also serve as your login to the Sonatype OSS system. (If you already have a Sonatype account, you can skip this step)
   2. Ask a Committer with release privileges (e.g. a previous release manager) to request that your Sonatype account be given release privileges to the "org.dspace" GroupID. This request should be submitted via the Sonatype JIRA system in the Open Source Project Repository Hosting project.
   3. Once Sonatype gives you the proper authorization, you should be able to login to the Sonatype OSS system using the same login/password you setup in Sonatype JIRA. You should also have access to publish new releases to the "org.dspace" GroupID.
   4. NOTE: The full details of signing up and getting access to Sonatype are also posted online here: Sonatype Maven Repository Usage Guide
3. You must generate and publish your own personal Code Signing Key (required by Sonatype). Here are two sites that give hints on how to do that:
   
   • See Sonatype instructions on creating a Code Signing Key.  Or, Fedora's instructions on Creating a Code Signing Key
   • How to Generate PGP Signatures with Maven (required for all Sonatype releases)
   • Make sure to publish your Key file to hkp://pgp.mit.edu, as this is the Key Server Sonatype uses for verification:
     
     • (e.g.) gpg --keyserver hkp://pgp.mit.edu --send-keys [yourKeyID]
       

       • [yourKeyId] can be found by running the following command and copying the alpha-numeric string after the "/" on the "pub" line 

         • gpg --list-keys
           

     • You can see if your key is already on that Key Server by visiting http://pgp.mit.edu and searching on your name

Update Maven settings.xml with Sonatype User Token

Generate / Access your Sonatype User Token via the instructions at https://central.sonatype.org/publish/generate-token/

DSpace's root pom.xml already has the correct staging and snapshot repositories listed in the OSS parent's '<distributionManagement>' section.  In order to deploy, you will need to add your Sonatype OSS username and password OSSRH user token to your local ~/.m2/settings.xml file. For example:

<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
                      http://maven.apache.org/xsd/settings-1.0.0.xsd">
  <servers>
    <!--Login User infoToken for Sonatype OSSRH SnapShotMaven repository -->
    <!-- To generate a User Token (random username & password), follow instructions at
         https://central.sonatype.org/publish/generate-token/ -->
    <server>
      <id>ossrh</id>
      <username>YourSonatypeUsername<<username>YourUserToken</username>
      <password>YourSonatypePassword<<password>YourUserTokenPassword</password>
    </server>
  </servers>
</settings>

...

• If any dependencies are listed with an "UNKNOWN" license, then that means that dependency failed to specify its OS License in their own Maven POM file. We will need to manually lookup the license for that project, and manually add it to our src/main/license/LICENSES_THIRD_PARTY.properties file which corrects all "UNKNOWN" licenses. Finally, rerun the command above to regenerate the new LICENSES_THIRD_PARTY based on this update.
• If any dependencies are listed under an INCOMPATIBLE License (GPL, AGPL, etc), then we need to take a closer look at that dependency.  It is possible that the dependency is dual-licensed and therefore may be listed multiple times in the generated LICENSES_THIRD_PARTY file. If so, that's fine. If not, we may need to remove that dependency prior to the release.
• If any Open Source Licenses are listed under multiple names (e.g. "BSD" vs. "BSD License" vs. "BSD licence"), then we may need to update our POM configurations for the codehaus license-maven-plugin to tell it to merge licenses of those names into one. Those configurations are in the Parent POM under the <licenseMerges> tag of this plugin: https://github.com/DSpace/DSpace/blob/mastermain/pom.xml#L406xml#L713

If the file was updated, commit it.

...