Versions Compared

Old Version 204

changes.mady.by.user Tim Donohue

Saved on

compared with

New Version 205

changes.mady.by.user Tim Donohue

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

With DSpace 6 we changed the maven plugin that pushes our releases to Sonatype. The configuration above is correct beginning with DSpace 6. In case you release a previous DSpace version, you'll need to copy the server section two times and change the id to sonatype-nexus-snapshots and sonatype-nexus-staging. A settings file that allows you to release all versions of DSpace would look like the following example:

 


Code Block
<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 info for Sonatype SnapShot repository-->
    <server>
      <id>ossrh</id>
      <username>YourSonatypeUsername</username>
      <password>YourSonatypePassword</password>
    </server>
    <!--Login info for Sonatype SnapShot repository-->
    <server>
      <id>sonatype-nexus-snapshots</id>
      <username>YourSonatypeUsername</username>
      <password>YourSonatypePassword</password>
    </server>
    <!--Login info for Sonatype Staging/Release repository-->
    <server>
      <id>sonatype-nexus-staging</id>
      <username>YourSonatypeUsername</username>
      <password>YourSonatypePassword</password>
    </server> </servers>
</settings>

...

Code Block
languagebash
unset MAVEN_OPTS

 


It's highly unlikely the configuration in your MAVEN_OPTS will be useful for the release. It's highly likely to cause problems. Better to be safe.

...

Info
titleVersion Numbering Convention for Language Packs

Note that the version numbering convention for Language Packs is always the same as the current DSpace release, with an additional .[sequence-number]. For example, the i18n modules for 3.0 were numbered as follows: 3.0.0, 3.0.1, etc.

...

  1. Checkout the Language Pack Module:

    1. git clone git@github.com:DSpace/dspace-api-lang.git dspace-api-lang

    2. cd dspace-api-lang

    3. git checkout master main 
      NOTE: always release language packs from the master main branch -- we do not use a maintenance branch for language packs.

  2. Do a Dry Run: mvn release:prepare -DdryRun=true
  3. Tag and Increment Version: mvn release:prepare -Dresume=false
    • Make sure to assign a version number of the format: [major].[minor].[sequence-number] (e.g. 5.0.0, 5.0.1, etc for 5.0 releases of language packs)
    • NOTE: The release process should suggest the correct version number by default
  4. Deploy Artifacts to Staging in Sonatype: mvn release:perform
  5. Verify and Release Staged Artifacts in Sonatype (see instructions at link)
  6. (For v6.x or below) Go back and run steps #1-5 above for the other language packs modules (dspace-xmlui-lang)

...

Info

NOTE: if you're skimming these instructions, you may be tempted to think you've already handled this step, because you have already released new language packs, as detailed above. If you think so, you probably have NOT yet completed the steps below. The steps below tell DSpace what version of language packs to use. The language packs you've released following the steps above won't ever get used if you don't do the steps below. This is an easy thing to miss. Don't. Just check, to be sure.

...


Once the Language Packs are released, you will probably need to modify the DSpace root pom.xml (https://github.com/DSpace/DSpace/blob/master/pom.xml) to reference the new version of the Language Packs. This should be similar to the following:

...

Code Block
mvn test -Dmaven.test.skip=false -DskipITs=false

...


Do a Dry Run
This step is not required, but performs a useful sanity check without committing any changes. From your clean, up-to-date copy of master/branch, run the following command (from [dspace-src]):
...
What to do if you get tagging Errors?
 

 Note
titleIf you receive a project dependency error
The mvn release:prepare command may fail to compile part way through the process, complaining that an internal project dependency is not met. If this occurs, don't worry. You just may need to ensure those dependencies get installed to your local cache.  To fix this, you should be able to run the following:
  1. mvn release:clean   (clean out any files created by the previous "mvn release:prepare")
  2. mvn install -Dmirage2.on=true
  3. mvn release:prepare -Dmirage2.on=true
...
 Note
If you run into issues, or need to perform the mvn release:perform from a different machine, it is possible to run it simply against the created tag in GitHub.
  1. Create a "dummy" [src]/release.properties file in your local DSpace source directory. It should simply state the basic SCM info for the tag you wish to release, e.g.
     Code Block
    # Location of DSpace's SCM. Keep this as-is.
scm.url=scm\:git\:git@github.com\:DSpace/DSpace.git
# Change this value to point at the tag in GitHub
# For example, this example tells "release:perform" to perform a release to Sonatype based on the 'dspace-6.0-rc1' tag.
scm.tag=dspace-6.0-rc1

  2. Run the specified mvn release:perform command (see above).  Maven will then proceed to checkout the specified tag into your [src]/target/checkout folder, package up the release and send it off to Sonatype.
 

Verify and Release Staged Artifacts in Sonatype
...
This is a known bug in Maven. The problem is that you likely have a 'dspace-xmlui-lang' or 'dspace-api-lang' folder at the same level as your [dspace-source] parent folder. Essentially, Maven located them and tried to add them into the build process (which it shouldn't have). The fix is to completely delete the "dspace-xmlui-lang" and "dspace-api-lang" folders, and try to rebuild DSpace.
 

Advice for future Release Coordinators
With a straight face assure the next Release Coordinator that "Maven is easy" and there is nothing to be afraid of, then put your feet up and open a beer.