Opencast Maven Repository
The Maven repository server maintains a copy of all the Java dependencies used by Opencast.
Setting-up Another Maven Repository
Having a repository server run in your local network can significantly improve the speed artifacts are retrieved while building Opencast.
There is a preconfigured Docker image for a Nexus server set-up for Opencast. To run an Opencast Nexus using Docker, follow these steps:
docker run \ --name mvncache \ -p 8000:8000 \ docker.io/lkiesow/opencast-maven-repository
-poption will map the internal port of the server in Docker to the port on the host machine.
Prefer a Specific Repository
If you did set-up a local repository or just want to select a specific global repository by default, you can use a
custom Maven configuration. To do that, create asettings file in
~/.m2/settings.xml like this:
<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"> <mirrors> <mirror> <id>opencast-osna</id> <name>Osnabrück Opencast Repository</name> <url>https://nexus.opencast.org/nexus/content/groups/public</url> <mirrorOf>opencast</mirrorOf> </mirror> </mirrors> </settings>
This example would add a mirror for the primary Opencast Maven repository, causing the Osnabrück repository to be the
preferred repository to use. You can find some example configurations in
Pushing artifacts to a Maven repository
Pushing to your local Maven repository
The following command will add a file to your local Maven repository. This is useful for testing if your artifacts are correctly placed prior to pushing to the mainline Nexus repository.
mvn install:install-file \ -Dfile=$filename \ -DgroupId=$groupId \ -DartifactId=$artifactId \ -Dpackaging=$packaging \ -Dversion=$version \ -DgeneratePom=$generatePom
|Variable||What it does||Example|
|filename||The path to the local file you want in your repository||audio.mp2|
|groupId||The Opencast group ID||org.opencastproject|
|artifactId||The artifact ID. This is the name of the artifact according to Maven||audio|
|packaging||The file type (effectively), this should match the filename's extension||mp2|
|version||The artifact's version||1.1|
|generatePom||Whether or not to generate a pom file automatically||true|
Pushing to Maven Central
Opencast hosts its maven artifacts on Maven Central. There are a few steps prior to being able to push to Sonatype's repo:
- Create a GPG key, and push the public key to a key server
- Sign up for an account on Sonatype's JIRA instance
- Let the QA Coordinator know about your user, they will comment on our repo creation ticket or create a new issue to give your user permissions
- Put the following in your
<settings> <servers> <server> <id>ossrh</id> <username>$username</username> <password>$password</password> </server> ... </servers> <profiles> <profile> <id>ossrh</id> <activation> <activeByDefault>true</activeByDefault> </activation> <properties> <gpg.keyname>$gpgKeyId</gpg.keyname> </properties> </profile> ... </profiles> </settings>
Snapshots are pushed automatically by the CI servers. For historical purposes, this is accomplished by:
Note: Please read this section entirely before running any commands. Maven Central does not allow you to change a release once it has been closed!
Pushing releases is similar to snapshots, with the added requirements that you also push:
- GPG signatures for the binaries, docs, and sources
This is automated with the
release profile. To push a release run
mvn nexus-staging:deploy -P release
This creates a staging repository (https://oss.sonatype.org/content/groups/staging/org/opencastproject/) for your artifacts. This is always safe to do - you can still rollback all changes with
If things do not look ok, fix the issue and redeploy. Once you are confident that everything is ok, you can run
This closes the staging repository, and runs the Sonatype-side tests for things like GPG signatures. If this fails, correct the issue locally, and redeploy. Once this succeeds, you have two options: drop (to destroy the release) or:
to permanently release the binaries in their current states.
Sometimes the deploy or close will fail, timing out after 5 minutes waiting for Sonatype. It will complain about violations of deploy rules - this may or may not actually be true. If you're confident that this is caused by a simple timeout and not something you have done use one of the following.
To reattempt a deploy use
This will avoid recompiling, retesting, and resigning all of the binaries.
To reattempt a close use