Contribute to the DSpace Development Fund
The newly established DSpace Development Fund supports the development of new features prioritized by DSpace Governance. For a list of planned features see the fund wiki page.
This document is intended to be kept up to date by the DSpace Release Team. It details the steps necessary to perform snapshot and official releases of DSpace and supporting Modules.
Table of Contents
Useful Sonatype Links
For lack of a better place at this time, here's some useful pages on Sonatype which detail the Sonatype Maven Release Process:
Release Numbering Convention
As of 2012 (DSpace 3.0), DSpace has moved to a new release numbering scheme/format. Release numbers will now only consist of two numbers.
Release Numbering Scheme: [major].[minor]
(e.g. 3.0, 3.1, 3.2, 4.0)
- Major Releases: incrementing the first number ('major') will represent a new MAJOR release of DSpace. A major release may include any or all of the following: new features, system improvements, architectural changes, bug fixes. All major releases end in ".0", so "3.0", "4.0", and "5.0" would all represent major releases.
- Minor (Bug-Fix) Releases: incrementing the second number ('minor') will represent a new MINOR release of DSpace. A minor release will only include bug fixes to an existing major release. For example, "3.1" and "3.2" would represent two minor releases which only include bug fixes to the "3.0" major release..
For more information see DSpace Release Numbering Scheme and the initial DSpace 3.0 Announcement
Small Exception for Language Packs Releases
The one exception is that the Language Packs (dspace-api-lang
and dspace-xmlui-lang
) use the numbering convention [major].[minor].[sequence-number]
(e.g. 3.0.0, 3.0.1, 3.1.0, etc.). This allows us to release new versions of the language packs more frequently than normal DSpace releases, as needed.
Prerequisites
Verify Release Privileges
To perform a release, you must have all of the following:
- Write access to the DSpace GitHub repository hosted at https://github.com/DSpace/DSpace. (All Committers should already have this, obviously)
- 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:
- 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)
- 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.
- 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.
- The full details of signing up and getting access to Sonatype are also posted online here: Sonatype Maven Repository Usage Guide
- You mustgenerate and publish your own personal Code Signing Key (required by Sonatype). Here are two sites that give hints on how to do that:
- 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
- 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
- (e.g.)
Update Maven settings.xml
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 to your local ~/.m2/settings.xml
file:
<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>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>
If you don't yet have a ~/.m2/settings.xml
file, you should create one, and copy the full contents above (obviously make sure to put in your username and password).
Use Maven 3 or above
Make sure you're using a recent version of Maven. As of this writing, Maven 3.0.3 or 3.0.4 is known to work.
For more information see the Prerequisites section of the Sonatype Maven Repository Usage Guide
Making a Snapshot Release (e.g. 'dspace-x.y-SNAPSHOT')
One Step Process
From a clean, up-to-date copy of master/branch, run the following command:
mvn clean javadoc:jar source:jar deploy
You will have to enter in your GPG passphrase (which you established when you created your Code Signing Key).
The snapshot will be immediately available in the public Sonatype repository: http://oss.sonatype.org/content/groups/public
Releasing a Single Module/Project
- If you'd like to release a Snapshot Release of that module, follow the instructions at: Making a Snapshot Release (e.g. 'dspace-x.y-SNAPSHOT')
- If you'd like to tag & release a new version of that module, use the module instructions at: Release DSpace Language Packs (I18N) Modules (NOTE: These instructions obviously have some specific notes around how the Language Packs modules are versioned. You obviously don't need to follow those versioning notes. Individual modules may have their own version schemes)
Making an Official Release (e.g. 'dspace-x.y' or 'dspace-x.y-rc1')
For More Information
These same steps are also covered in the Sonatype Maven Repository Usage Guide
Release DSpace Language Packs (I18N) Modules
If possible, you should release the DSpace Language Packs (i18n modules) before the main release. Oftentimes, it's best to release these one or two days prior to the DSpace release (that way they've already propagated out to the Maven repository).
At the moment the i18n modules are maintained in two separate GitHub projects. There are currently two i18n modules you will need to release:
Version 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 the 1.8.0 release are numbered as follows: 1.8.0.0, 1.8.0.1, etc. However, for 3.0, the i18n modules will be numbered as follows: 3.0.0, 3.0.1, etc.
For each module, perform the full release steps that follow. To save space, the steps are only listed for one of the modules (but don't forget to run it for both language packs):
- Checkout the Language Pack Module:
git clone git
@github
.com:DSpace/dspace-api-lang.git dspace-api-lang
cd dspace-api-lang
git checkout master
- Do a Dry Run:
mvn release:prepare -DdryRun=true
- 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. 3.0.0, 3.0.1, etc for 3.0 releases of language packs) - NOTE: The release process should suggest the correct version number by default
- Make sure to assign a version number of the format:
- Deploy Artifacts to Staging in Sonatype:
mvn release:perform
- Verify and Release Staged Artifacts in Sonatype (see instructions at link)
- Go back and run steps #1-5 above for the other language packs modules (dspace-xmlui-lang)
Final Commits & Preparation
Double Check Language Packs' Version Ranges
Once the Language Packs are released, you may 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:
If possible, you'd only want to commit this after the i18n modules are available in the Maven Repository. But, if you are in a rush, you can commit this change earlier (though be warned that this will break the build process for anyone who hasn't manually installed the i18n modules to his/her local ~/.m2/
directory).
In the main pom.xml, provide the proper version range for each language pack. In the below example, we are saying to use any language pack version which is at least version 3.0.0, but is less than version 4.0.0:
<!-- DSpace Localization Packages --> <dependency> <groupId>org.dspace</groupId> <artifactId>dspace-api-lang</artifactId> <version>[3.0.0,4.0.0)</version> </dependency> <dependency> <groupId>org.dspace</groupId> <artifactId>dspace-xmlui-lang</artifactId> <version>[3.0.0,4.0.0)</version> <type>war</type> </dependency>
Ensure Documentation is Updated Appropriately
Hopefully, you've already been talking with others about getting Documentation updated!
You should also double check that the following "main pages" are updated in the Documentation:
- Preface- Should contain a very basic overview of the Release. Make sure the Release number is updated here!
- NOTE: For Subminor releases (bug-fix-only releases), you may want to leave all information about the previous major release, and just enhance the content to state that this was a bug-fix release, and list any new contributors, etc.
- Installation - Obviously make sure the Installation Documentation is updated for this Release
- Upgrading a DSpace Installation - Same for the Upgrade Documentation, make sure it's up to date
- History- Make sure the online History for this latest Release is included. You should be able to just edit the page, copy the fancy code that generated the history for another release, and update the version numbers. For example, copy the previous release's History section and change the release numbers as follows:
- You'll notice all the release History is generated via the
jiraissue
plugin. In theurl
argument for that plugin, you should find the DSpace version number embedded in the querystring like: "... AND+fixVersion+%3D+%221.7.0%22 ..." If you look closely, you'll see the 'fixVersion' is set to "1.7.0" in that search string. All you should need to do is update that version number! Also make sure to update the
title
argument for thatjiraissue
plugin to list the proper version number informationObviously, this is just a brief reminder of important areas of Documentation which always require updates. There's surely other areas, like Configuration section, which will require some updates for your release.
- You'll notice all the release History is generated via the
Ensure PDF version of Wiki Documentation is in GitHub
Make sure the latest Wiki-based Documentation has been exported as PDF and committed to [dspace-src]/dspace/docs/ in GitHub.
How to Generate PDF Documentation
See this DSpace documentation management guide: How To Export Downloadable Docs from Wiki
Double Check Contents of all README (and similar) files in GitHub
Make sure that the contents of all README, LICENSE, LICENSES_THIRD_PARTY, NOTICE files are up-to-date in GitHub. These files reside in [dspace-src]. If anything is out-of-date, make sure to update it and commit the proper changes before continuing.
Pay close attention to the "LICENSES_THIRD_PARTY" file. You should attempt to determine if any third-party dependencies were added or removed and update their licensing information in this file. Information on the Maven commands that may come in handy when updating this file can be found in the Notes at the end of the "LICENSES_THIRD_PARTY" file.
Checkout Master or Branch to Release
Checkout a fresh copy of the to-be-released version either from a branch or master. For example:
git clone git@github.com:DSpace/DSpace.git ~/dspace-release cd ~/dspace-release git checkout master
Note: do not just re-use an old working copy of the DSpace Master branch, for obvious reasons, you don't want your own work in progress sneaking into the release. It's also important to use the SSH repository path as noted above (NOT the https URL), otherwise you will be prompted for your GitHub credentials during the release process. More than once. Save yourself some time, be sure to use the SSH path.
Update your Local Maven Cache (optional)
Before starting the release, you may wish to ensure your local maven cache (~/.m2/repository
) is completely up-to-date by running (from [dspace-src]
):
mvn install
Updating your local maven cache will help to ensure that the release process goes more smoothly, and should help you to avoid any errors having to do with Maven being unable to locate any particular dependencies. That being said, this step actually may not be necessary, if our release process is working correctly.
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]
):
mvn release:prepare -DdryRun=true
You will have to enter in your GPG passphrase (which you established when you created your Code Signing Key).
If you notice an issue or an error occurs, you can re-run the Dry Run using the following command:
mvn release:prepare -DdryRun=true -Dresume=false
You can also clean up any of the release files that the Dry Run created, and just re-run it.
mvn release:clean
mvn release:prepare -DdryRun=true
Tag and Increment Version
This step will set the version declared in the project's pom.xml files, commit the changes to master/branch, tag the release, and finally, check in the master/branch change that increments the next development version (e.g. x.y-SNAPSHOT) in the pom.xml files. Run the following (from [dspace-src]
):
mvn release:prepare -Dresume=false
(Optionally, you may also include the parameters -Dusername=YourGitHubUsername -Dpassword=YourGitHubPassword
at the end of the above command, though I've not found these to be necessary)
The above command will ask you three basic questions. Here are sample answers for DSpace 3.0:
"What is the release version for: XXX" : 3.0
- NOTE: This is the release # to put in the final tagged Maven POMs.
- Examples:
- For a "3.0" final release, it should look like:
3.0
- For a "3.0 Release Candidate #1" release, it should look like:
3.0-rc1
- For a "3.0" final release, it should look like:
"What is SCM release tag or label for: XXXX" : dspace-3.0
- NOTE: This is the tag name in GitHub.
- Examples:
- For a "3.0" final release, it should look like:
dspace-3.0
- For a "3.0 Release Candidate #1" release, it should look like:
dspace-3.0-rc1
- For a "3.0" final release, it should look like:
"What is the new development version for: XXXX" : 3.1-SNAPSHOT
- NOTE: This is the next release number which all POMs should be incremented to on "master"branch.
- Examples:
- For a "3.0" final release (3.0), the next version should be:
3.1-SNAPSHOT
- For a "3.0 Release Candidate #1" release (3.0-rc1), the next version should be:
3.0-rc2-SNAPSHOT
- For a "3.0" final release (3.0), the next version should be:
You will also have to enter in your GPG passphrase (which you established when you created your Code Signing Key).
Many JavaDoc WARNING messages will scroll by
As the release process scrolls by, you likely will see a LOT of "WARNING" messages. Don't worry, these should be just Javadocs warnings, and can be safely ignored. Just be patient, and see if it all succeeds in the end.
What do successful tagging results look like?
Assuming everything worked right, you should see ALL the following changes in GitHub:
- A newly tagged version of DSpace under: https://github.com/DSpace/DSpace/tags (and the "pom.xml" files in that tagged version should have <version> tags that correspond to the release version)
- All "pom.xml" files in the master branch should be updated to the next version.
You should also see a results message like this. (Don't worry about the "SKIPPED" messages, those are normal, as the actual release process just runs from the "DSpace Parent Project")
[INFO] ------------------------------------------------------------------------ [INFO] Reactor Summary: [INFO] [INFO] DSpace Parent Project ............................. SUCCESS [2.320s] [INFO] DSpace Services Framework :: API and Implementation SKIPPED [INFO] DSpace Kernel :: API and Implementation ........... SKIPPED [INFO] DSpace Addon Modules .............................. SKIPPED [INFO] DSpace Kernel :: Additions and Local Customizations SKIPPED [INFO] DSpace XML-UI (Manakin) ........................... SKIPPED [INFO] DSpace XML-UI (Manakin) :: Local Customizations ... SKIPPED [INFO] DSpace LNI ........................................ SKIPPED [INFO] DSpace LNI :: Local Customizations ................ SKIPPED [INFO] DSpace JSP-UI ..................................... SKIPPED [INFO] DSpace JSP-UI :: Local Customizations ............. SKIPPED [INFO] DSpace SWORD ...................................... SKIPPED [INFO] DSpace SWORD :: Local Customizations .............. SKIPPED [INFO] DSpace SWORD v2 ................................... SKIPPED [INFO] DSpace SWORD v2 :: Local Customizations ........... SKIPPED [INFO] DSpace SOLR :: Local Customizations ............... SKIPPED [INFO] DSpace OAI 2.0 .................................... SKIPPED [INFO] DSpace OAI 2.0 :: Local Customizations ............ SKIPPED [INFO] DSpace Assembly and Configuration ................. SKIPPED [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS [INFO] ------------------------------------------------------------------------
What to do if you get tagging Errors?
If 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:
mvn release:clean
(clean out any files created by the previous "mvn release:prepare")mvn install
mvn release:prepare
Backing out of changes
If backing out of this step is needed for any reason, the following will restore the github repository and your working copy to the state it was previously in:
mvn release:rollback
- Warning: running a "mvn release:rollback" will perform an immediate, automatic push to GitHub master, rolling back any previously committed POM version changes.
- If you want to avoid the immediate, automatic push to GitHub master, you may be able to use "
mvn release:clean
" to just clean up the locally made release preparations.
- Now delete the tag in GitHub (local & remote)
git tag -d dspace-x.y
git push origin :refs/tags/dspace-x.y
Deploy Artifacts to Staging in Sonatype
This step will sign, checksum, and push all release artifacts (including javadocs and sources) to the Sonatype staging repository (http://oss.sonatype.org/). Run the following (from [dspace-src]
):
mvn release:perform
You should be prompted by Maven to specify your GPG passphrase (which you established when you created your Code Signing Key). If you run into any issues, it's possible to specify your GPG key and passphrase as arguments to the above command (e.g. -Darguments="-Dgpg.keyname=YourKeyId -Dgpg.passphrase=YourKeyPassword"
)
If you need to re-deploy
If any errors or problems occur during the deploy, you can re-run mvn release:perform
safely after fixing those issues (re-running it will just overwrite existing staged contents).
Verify and Release Staged Artifacts in Sonatype
For screenshots and more details on this step, visit the Sonatype Repository Usage Guide's section on Releasing your artifacts
- Login to http://oss.sonatype.org/
- Click "Staging Repositories" in the left column, then select the checkbox next to the staged repository on the right. The contents of it will open up at the bottom of the page.
- With the staged repository still selected, click the "Close" button at the top.
Download and test that the artifacts in staging are exactly as they should be once deployed to central.
If You Need to Revert Back before Releasing
If anything is incorrect, select the staged repository and select "Drop". After the problem is resolved, you can re-deploy the artifacts to staging and verify them again. To re-deploy an already-tagged release:
mvn release:perform -Dtag=dspace-x.y -DconnectionUrl=scm:git:git@github.com:DSpace/DSpace.git -Darguments="-Dgpg.keyname=YourKeyId -Dgpg.passphrase=YourKeyPassword"
If everything looks good, select the repository and select "Release". The artifacts should be synced to Maven central (http://repo2.maven.org/maven2/org/dspace/) within 2 hours.
Once Released, There is No "Undo" Option
Once you select "Release", there is no way to "undo" the release. If any major issues are found, you'll have to increment the version number and perform a new bug-fix release.
Create the Distribution Zips for SourceForge
The previous actions will have checked out the release tag into the target directory under [dspace-src]/target/checkout/dspace/
. Navigate to that directory and execute the creation of the distributions using the following command. This will create two zip, bzip and gzipped files in the target directory. One set of files is the "binary" release, and the other set is the source release.
(Note: If you've already removed the target/checkout
directory, you can also checkout a fresh copy of the newly tagged version and run this command from the [dspace-src]/dspace/
directory.)
localhost$ cd target/checkout/dspace/ localhost$ mvn package -Pdistributions [INFO] Scanning for projects... [INFO] [INFO] ---------------------------------------------------------------------------- [INFO] Building DSpace Assembly and Configuration 3.0 [INFO] ---------------------------------------------------------------------------- .... [INFO] --- maven-assembly-plugin:2.2.1:single (default) @ dspace --- [INFO] Reading assembly descriptor: src/main/assembly/release.xml [INFO] Reading assembly descriptor: src/main/assembly/src-release.xml [INFO] Building zip: [full-path-to-dspace-src]/dspace/target/dspace-3.0-release.zip [INFO] Building tar: [full-path-to-dspace-src]/dspace/target/dspace-3.0-release.tar.gz [INFO] Building tar: [full-path-to-dspace-src]/dspace/target/dspace-3.0-release.tar.bz2 [INFO] Building zip: [full-path-to-dspace-src]/dspace/target/dspace-3.0-src-release.zip [INFO] Building tar: [full-path-to-dspace-src]/dspace/target/dspace-3.0-src-release.tar.gz [INFO] Building tar: [full-path-to-dspace-src]/dspace/target/dspace-3.0-src-release.tar.bz2 [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS [INFO] ------------------------------------------------------------------------
Upload to SourceForge
Upload both the source and binary releases to Sourceforge.net. You can either upload them via the web interface, or copy them over via scp
or other command line tools. If you want to copy the files from command line, follow the directions found here: http://apps.sourceforge.net/trac/sourceforge/wiki/File%20management%20service
Using scp
to copy to the "DSpace Stable" file directory: (example for 1.8.0 final)
(NOTE: You will need to first create the 'DSpace Stable/1.8.0' directory via SourceForge's Admin UI)
scp <files> <username>,dspace@frs.sourceforge.net:"/home/frs/project/d/ds/dspace/DSpace\\ Stable/1.8.0/"
Using scp
-r to copy to the "DSpace Release Candidate" file directory: (example for 1.8.0-rc2)
(NOTE: You will need to first create a folder in your target directory, named "1.8.0-rc2" or whatever the name of the release is, and then mv all the tar.gz and zip files to that folder... you're going to recursively scp the entire contents of that folder to Sourceforge)
scp -r <release_folder_with_zips> <username>,dspace@frs.sourceforge.net:"/home/frs/project/d/ds/dspace/DSpace\\ Release\\ Candidate/"
After the Release is Finished
Don't Announce Until Maven Packages Have Propagated
You must wait for all the packages to be available at http://repo2.maven.org/maven2/org/dspace/ before you announce the release. Until the DSpace packages are available in the Maven repository, no one else will be able to build DSpace using Maven.
- Add the new contributors to the list: DSpaceContributors
- Coordinate Announcements with DuraSpace Staff:
- Announcement on dspace.org, duraspace.org, twitter
- Ensure that the Latest Releasepage on dspace.org is updated.
- Plus, ask dspace.org admins to upload latest documentation in PDF/HTML format
- Announce on all DSpace mailing lists
- Link announcement on Home of DSpace Wiki, change any version numbers listed on that page.
- Update Wiki pages, particularly these pages which refer to the Current and Next Releases:
- Current Release
- Next Release Status
- RoadMap
- NOTE: See DSpace Wiki Style Guide for notes on how to actually edit the above Redirect pages
- Also, update the Documentation Wiki area! Specifically:
- All Documentation page -> Has current release info
- Homepage for the current Documentation (e.g. DSpace 1.8 Documentation) -> Has links to download latest version of DSpace
- For major releases, create a new branch in GitHub for any upcoming bug-fix releases:
- E.g., after the 3.0 release, we created a 3.x branch for any subsequent bug fix releases.
- To automatically create a branch, you may be able to use the release:branch command (NOTE: untested, but it should work! once we test it out, this may be the best practice way of creating a branch).
To manually create a branch, run commands similar to:
git clone git@github.com:DSpace/DSpace.git branchit cd branchit git checkout -b dspace-3_x dspace-3.0 git push --set-upstream origin dspace-3_x
Then, go back to your
master
checkout, and make sure to update its version numbers in the pom.xml files by running the following:git checkout master mvn release:update-versions
(Remember to enter in the next appropriate major version number. E.g. After releasing 3.0,
master
should be updated to "4.0-SNAPSHOT", while the new3_x
branch should be at "3.1-SNAPSHOT")- NOTE: the
update-versions
command doesn't always work perfectly. You will want to try a complete rebuild of DSpace before committing anything, as it sometimes misses updating a few version numbers. - Push your verified changes back to GitHub.
- You'll also need to ensure that all version numbers and the
<scm>
section is appropriate in the pom.xml files of your new Branch. Remember, the<scm>
configurations should point at the branch, rather than back atmaster
.
- For major releases, after you create the maintenance branch (see above), DuraSpace Bamboo should automaticallynotice the new branch and add it to our existing Bamboo build plan.
- NOTE: Bamboo assumes the branch name will start with "dspace-"
- You may want to jump over to DuraSpace Bamboo to ensure that the branch now appears under our main project: https://bamboo.duraspace.org/browse/DST-TRUNK/branches
- Updates to JIRA:
- Move any uncompleted issues to the next DSpace version tag in JIRA.
- Ask a JIRA Administrator to close out the release in JIRA (this will ensure no new issues can be added to that release).
Possible Errors you may Encounter
"Could not find model file" error (with language packs)
If you encounter one of these errors when building/packaging DSpace:
FATAL ERROR: "Reason: Could not find the model file '../dspace-xmlui-lang'. for project unknown"
OR
FATAL ERROR: "Reason: Could not find the model file '../dspace-api-lang'. for project unknown"
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.