Page History

...

Most people will have stopped reading by now, but if you're part of the unlucky few, then you have my condolences.

Self-Hosted via Docker

To run your own test Nexus repository via the official Docker image:

...

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).

...

Deploying a Single Artifact

Once your project ticket has been approved, you can add the following block to your project's pom.xml fileuse a syntax similar to that of install-file to deploy a single artifact to a remote Nexus repo:

# Deploying a SNAPSHOT (non-release) artifact
$ 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


# Deploying a release (non-SNAPSHOT) artifact
$ 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

NOTE: SNAPSHOTs will overwrite each other... need to determine how to deploy a set of SNAPSHOT artifacts. Maybe manually bundling them up before calling deploy-file?

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:

        <distributionManagement>    <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><!-- When your version ends with "-SNAPSHOT", it will be deployed here -->
          <snapshotRepository>
  <url>https://          <id>ossrh</id>
            <url>https://oss.sonatype.org/servicecontent/localrepositories/staging/deploy/maven2/</snapshots</url>
          </repository>snapshotRepository>


        </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:

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:

  <!-- 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:

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:

1. 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
2. Final pom.xml must NOT include:
   1. <repositories> tags
   2. <pluginRepositories> tags
3. Final 
4. 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
5. Final pom.xml must NOT include:
   1. <repositories> tags
   2. <pluginRepositories> tags
6. 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)

...

	    <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>

Third-Party Dependencies

To sync third-party dependencies

1. Ask for the developers' permission to publish their code, consult the license, etc
   1. DO NOT publish other people's code without their permission!
2. Locate the source code (if possible)

   1. If found, generate a JAR containing the source code:

      Code Block
      language bash
      jar -cvf indri-5.11-sources.jar *

      
      

   2. If found, generate JavaDoc HTML from the source code and bundle it into a separate JAR:

      Code Block
      language bash
      mkdir -p ./target/javadoc javadoc -d ./target/javadoc lemurproject.indri cd target/javadoc jar -cvf indri-5.11-javadoc.jar *

      NOTE: Scala projects can supposedly skip this step

3. Locate compiled binaries (you can choose to download them, or build them yourself if you are able)

4. Author a simple POM for this dependency. Below is an example POM.xml that might be used for edu.illinois.lis.indri:

   Code Block
   language bash
   <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>edu.illinois.lis</groupId> <artifactId>indri</artifactId> <version>5.11</version> <name>Indri 5.11</name> <description>Indri is a text search engine developed at UMass. It is a part of the Lemur project.</description> <url>https://sourceforge.net/projects/lemur/</url> <licenses> <!-- Indri actually uses BSD-old / "original BSD", but its link is no longer available via opensource.org. This is likely due to the controversy surrounding the 4th clause --> <license> <name>BSD-3-Clause</name> <url>https://opensource.org/licenses/BSD-3-Clause</url> </license> </licenses> <scm> <connection>scm:svn:https://svn.code.sf.net/p/lemur/code/ lemur-code</connection> <developerConnection>scm:svn:https://svn.code.sf.net/p/lemur/code/ lemur-code</developConnection> <url>scm:svn:https://sourceforge.net/p/lemur/code/HEAD/tree/indri/tags/release-5.11/</url> </scm> <developers> <developer> <name>David Fisher</name> <email>dfisher@cs.umass.edu</email> <organization>University of Massachusetts at Amherst</organization> <organizationUrl>http://www.umass.edu/</organizationUrl> </developer> <developer> <name>Stephen Harding</name> <email>harding@hobart.cs.umass.edu</email> <organization>University of Massachusetts at Amherst</organization> <organizationUrl>http://www.umass.edu/</organizationUrl> </developer> <developer> <name>Cameron VandenBerg</name> <email>cmw2@andrew.cmu.edu</email> <organization>Carnegie Mellon University</organization> <organizationUrl>http://www.cmu.edu/</organizationUrl> </developer> </developers> </project>

   
   

   
   

5. Sign all artifacts with your GPG key (*.pom, *.jar, *-sources.jar, *-javadoc.jar):

   Code Block
   language bash
   gpg -ab indri-5.11.pom gpg -ab indri-5.11.jar gpg -ab indri-5.11-sources.jar gpg -ab indri-5.11-javadoc.jar

   
   

   1. This will produce a .asc file for each artifact

      Code Block
      language bash
      lambert8:5.11 lambert8$ ls -al total 65168 drwxr-xr-x 14 lambert8 staff 476 Jun 2 16:50 . drwxr-xr-x 5 lambert8 staff 170 Jun 2 15:48 .. -rw-r--r-- 1 lambert8 staff 1880 Jun 2 15:31 LICENSE -rw-r--r-- 1 lambert8 staff 93941 Jun 2 15:18 indri-5.11-javadoc.jar -rw-r--r-- 1 lambert8 staff 488 Jun 2 15:42 indri-5.11-javadoc.jar.asc -rw-r--r-- 1 lambert8 staff 16384085 Jun 2 15:41 indri-5.11-sources.jar -rw-r--r-- 1 lambert8 staff 488 Jun 2 15:42 indri-5.11-sources.jar.asc -rw-r--r-- 1 lambert8 staff 259518 May 22 10:54 indri-5.11.jar -rw-r--r-- 1 lambert8 staff 488 Jun 2 15:42 indri-5.11.jar.asc -rw-r--r-- 1 lambert8 staff 2035 Jun 2 16:49 indri-5.11.pom -rw-r--r-- 1 lambert8 staff 488 Jun 2 16:49 indri-5.11.pom.asc

      
      

6. Be sure to include a copy of the LICENSE, if this dependency requires that it be included in source/binary distributions. 

7. Bundle everything up and Stage this release in the same way as described above:

   Code Block
   language bash
   jar

...

1. -cvf indri-5.11-bundle.jar *.jar *.pom *.asc LICENSE