Publishing Artifacts (Advanced)

To easily run your own test Nexus repository via the official Docker (untested)image:

Code Block

language	bash

$ docker run -d -p 8081:8081 --name nexus sonatype/nexus:oss

You should then be able to follow the steps below (untested) using the IP/hostname of this machine and port 8081.

You can test it with the following command:

Code Block

language	bash

$ curl -u admin:admin123 http://localhost:8081/service/metrics/ping

Open-Source Software Repository Hosting (OSSRH)

...

For a more long-term solution for hosting your (open-source) Maven artifacts, you can follow these steps to deploy them to OSSRH.

...

.

Choosing Project Coordinates

See http://central.sonatype.org/pages/choosing-your-coordinates.html

First and foremost, your Maven groupId should be the reverse of a FQDN over which you have some management rights. For example, edu.illinois.lis or org.nationaldataservice or org.ndslabs.* might be acceptable groupIds for the biocaddie code.

Ideally, your Maven groupId and Java packages should match or at the very least be fairly similar.

Create a Ticket on the Sonatype JIRA

If you don't already have one, create an account on the Sonatype JIRA
Plug your JIRA account credentials into the <servers> block of your settings.xml file (on OS X, this was located at /usr/local/Cellar/maven/3.5.0/libexec/conf/settings.xml):

Code Block

language	bash

  <servers>
    <server>
      <id>ossrh</id>
      <username>YOUR_JIRA_USERNAME</username>
      <password>YOUR_JIRA_PASSWORD</password>
    </server>
  </servers>

Next, create a New Project ticket on the Sonatype JIRA describing the artifacts that you plan to deploy to OSSRH.

The Sonatype team will reach out to confirm that you "own" the domain used for the groupId (see above), and can answer any questions you might have.
The turnaround time was really quick for my ticket, and they will respond in the comments with next steps or problems (if any arise).

Configuring your POM for Deployment

Once your project ticket has been approved, you can add the following block to your project's pom.xml file:

Code Block

language	bash

        <distributionManagement>
          <!-- When your version ends with "-SNAPSHOT", it will be deployed here -->
          <snapshotRepository>
            <id>ossrh</id>
            <url>https://oss.sonatype.org/content/repositories/snapshots</url>
          </snapshotRepository>


          <!-- When your version does not end with "-SNAPSHOT", it will be deployed here -->
          <repository>
            <id>ossrh</id>
            <url>https://oss.sonatype.org/service/local/staging/deploy/maven2/</url>
          </repository>
        </distributionManagement>

NOTE: The <id> here should match the <servers> entry in your settings.xml.

You should now be able to deploy to the above repositories by running the following command:

Code Block

language	bash

mvn deploy

Syncing to Maven Central

OSSRH will even sync your released artifacts with Maven Central on your behalf, but still has a strict list of requirements for artifacts synced to Maven Central.

See http://central.sonatype.org/pages/requirements.html

In general, the requirements are as follows:

Final pom.xml must include:
1. Project coordinates: groupId / artifactId / version
2. Project name and description
3. License information
4. Developer information
5. SCM information
Final pom.xml must NOT include:
1. <repositories> tags
2. <pluginRepositories> tags
Final bundle.jar must include:
1. Project POM (i.e. ir-utils-0.1.0.pom)
2. Compiled JARs (i.e. ir-utils-0.1.0.jar)
3. JavaDoc JAR alongside each compiled JAR (i.e. ir-utils-0.1.0-javadoc.jar)
4. Sources JAR alongside each compiled JAR (i.e. ir-utils-0.1.0-sources.jar)
5. GPG signatures for all of the above (i.e. ir-utils-0.1.0.jar.asc, ir-utils-0.1.0-javadoc.jar.asc, etc)

You will then need to comment back on your OSSRH ticket after promoting your first release for them to enable sync to Maven Central.

After that, any future releases that you promote from the staging repository will be automatically synced to Maven Central (within a few hours).

Generating JavaDoc via Maven

Add the following to your pom.xml to generate a *-javadoc.jar alongside each JAR that is output during the package phase of your build:

Code Block

language	bash

        <build>
          <plugins>
            <!-- More plugins... -->         
           
			<!-- Maven JavaDoc Plugin -->
			<plugin>
				<groupId>org.apache.maven.plugins</groupId>
				<artifactId>maven-javadoc-plugin</artifactId>
				<version>2.10.4</version>
				<configuration>
					<show>private</show>
					<nohelp>true</nohelp>
				</configuration>
				<executions>
					<execution>
						<id>attach-javadocs</id>
						<phase>package</phase>
						<goals>
							<goal>jar</goal>
						</goals>
					</execution>
				</executions>
			</plugin>

            <!-- More plugins... -->

          </plugins>
        </build>

Generating Sources via Maven

Add the following to your pom.xml to generate a *-sources.jar alongside each JAR that is output during the package phase of your build:

Code Block

language	bash

        <build>
          <plugins>
            <!-- More plugins... -->


			<!-- Maven Sources Plugin -->
			<plugin>
				<groupId>org.apache.maven.plugins</groupId>
				<artifactId>maven-source-plugin</artifactId>
				<version>3.0.1</version>
				<executions>
					<execution>
						<id>attach-sources</id>
						<phase>package</phase>
						<goals>
							<goal>jar</goal>
						</goals>
					</execution>
				</executions>
			</plugin>
            <!-- More plugins... -->

          </plugins>
        </build>

Signing Your Artifacts via Maven

See http://central.sonatype.org/pages/working-with-pgp-signatures.html

This will ensure that consumers of your artifacts can verify the authenticity of those that they download (similar to MD5 checksum).

Add the following to your pom.xml to generate a *.asc alongside each output file during the verify phase of your build:

Code Block

language	bash

        <build>
          <plugins>
            <!-- More plugins... -->


            <!-- Maven GPG Plugin -->
			<plugin>
				<groupId>org.apache.maven.plugins</groupId>
				<artifactId>maven-gpg-plugin</artifactId>
				<version>1.6</version>
				<executions>
					<execution>
						<id>sign-artifacts</id>
						<phase>verify</phase>
						<goals>
							<goal>sign</goal>
						</goals>
					</execution>
				</executions>
			</plugin>


            <!-- More plugins... -->


          </plugins>
        </build>

NOTE: You will now be asked for your passphrase when running "mvn deploy"

NOTE: If your build fails with "gpg: signing failed: Inappropriate ioctl for device", run the following before the retrying the mvn command:

Code Block

language	bash

export GPG_TTY=$(tty)

Generate a Keypair

If you don't already have one, you will need to generate a GPG key with which you can sign your artifacts.

You will need the gnupg command line tool (on OSX, this can be installed via brew):

Code Block

language	bash

$ gpg --gen-key

Upload to Keyserver

Once you have generated a keypair, you will need to upload your public key to a public keyserver.

...

where <YOUR_KEY_ID_WHICH_WILL_BE_FAIRLY_LONG> is pulled from the output above

Manually Signing a Single File

To sign a file with your GPG key:

...

This will output a .asc file that should be included with alongside the file that produced itthe signature.

Verifying GPG Signatures

As a consumer, you can verify the authenticity of the Maven artifacts by using the gpg command line tool:

...

This will output the signature data from the .asc file, which should give you some confidence that the artifacts were not modified or replaced by a malicious party.

Third-Party Dependencies

Bringing It All Together

If you followed all of the above steps, then running the following command should build up all of the necessary artifacts and deploy them to the appropriate To publish a single SNAPSHOT artifact to a repository:

Code Block

language	bash

$ mvn deploy:deploy-file -Dfile=./indri-5.11.jar -DgroupId=edu.illinois.lis -DartifactId=indri -Dversion=5.11-SNAPSHOT -Dpackaging=jar -Durl=https://oss.sonatype.org/content/repositories/snapshots/ -DrepositoryId=ossrh

For staging a new release:

Code Block

language	bash

$ mvn deploy:deploy-file -Dfile=./indri-5.11.jar -DgroupId=edu.illinois.lis -DartifactId=indri -Dversion=5.11 -Dpackaging=jar -Durl=https://oss.sonatype.org/service/local/staging/deploy/maven2 -DrepositoryId=ossrh

...

Staging a New Release

Syncing to Maven Central

See http://central.sonatype.org/pages/requirements.html

OSSRH will sync your released artifacts with Maven Central on your behalf, but still has a strict list of requirements for artifacts synced to Maven Central.

In general, the requirements are as follows:

...

Project POM (i.e. pom.xml)
Compiled JAR (i.e. ir-utils-0.1.0.jar)
JavaDoc JAR (i.e. ir-utils-0.1.0-javadoc.jar)
Sources JAR (i.e. ir-utils-0.1.0-sources.jar)
GPG signatures for all of the above (i.e. ir-utils-0.1.0.jar.asc, ir-utils-0.1.0-javadoc.jar.asc, etc)

...

Project coordinates: groupId / artifactId / version
Project name and description
License information
Developer information
SCM information

clean package gpg:sign install:install deploy:deploy

This single command will:

Clear out your existing build artifacts
Compile and package up your code into a JAR
Generate JavaDoc from your project and package it as a JAR
Package up your source code as a JAR
Sign the JAR and POM files with your GPG key
Install the resulting artifacts into your local Maven cache
Deploy the resulting artifacts into the remote Nexus repository

Staging a New Release

Insert snippet about Maven Release Plugin

Code Block

language	bash

	    <build>
		  <plugins>
            <!-- More plugins... -->

			<!-- Maven Release Plugin -->
			<plugin>
				<groupId>org.apache.maven.plugins</groupId>
				<artifactId>maven-release-plugin</artifactId>
				<version>2.5.3</version>
				<configuration>
					<mavenExecutorId>forked-path</mavenExecutorId>
					<useReleaseProfile>false</useReleaseProfile>
					<arguments>-Psonatype-oss-release</arguments>
				</configuration>
			</plugin>


            <!-- More plugins... -->


          </plugins>
        </build>

...

Page tree

Versions Compared

Old Version 4

New Version 5

Key

Publishing Artifacts (Advanced)

Open-Source Software Repository Hosting (OSSRH)

Choosing Project Coordinates

Create a Ticket on the Sonatype JIRA

Configuring your POM for Deployment

Syncing to Maven Central

Generating JavaDoc via Maven

Generating Sources via Maven

Signing Your Artifacts via Maven

Generate a Keypair

Upload to Keyserver

Manually Signing a Single File

Verifying GPG Signatures

Third-Party Dependencies

Bringing It All Together

Staging a New Release

Syncing to Maven Central

Staging a New Release

Page tree

Page History

Versions Compared

Old Version 4

New Version 5

Key

Publishing Artifacts (Advanced)

Open-Source Software Repository Hosting (OSSRH)

Choosing Project Coordinates

Create a Ticket on the Sonatype JIRA

Configuring your POM for Deployment

Syncing to Maven Central

Generating JavaDoc via Maven

Generating Sources via Maven

Signing Your Artifacts via Maven

Generate a Keypair

Upload to Keyserver

Manually Signing a Single File

Verifying GPG Signatures

Third-Party Dependencies

Bringing It All Together

Staging a New Release

Syncing to Maven Central

Staging a New Release