For some projects, this will be far enough to sustain development and testing.

Central Sync Requirements (Expert)

NOTE: Below I use OSSRH as an example, but this should work for any Accepted Hosting Repository.

OSSRH (and probably other approved repository hosts) will even sync your released artifacts with Maven Central on your behalf.

Sadly, this process did not seem to lift any of the strict requirements for the artifacts synced/

See httpSee https://bookscentral.sonatype.comorg/nexus-book/reference/staging-repositories.html

At some point, you will likely want to assemble a release (non-SNAPSHOT) version of the code that people can be confident will not change out from under them suddenly. This is where releases come in - since they are unique and permanent, users can consume released artifacts confidently without fear of them changing in the future. without warning.

First, perform a full build of your project using whatever options are necessary for your selected plugins, and jump into the target/ folder where the build output should be:

Code Block

language	bash

$ mvn clean package gpg:sign install:install deploy:deploy 
$ cd target/

NOTE: For complex project with multiple subprojects, it may be best to look into the Maven Bundle Plugin.

Bundle your build artifacts (JAR / POM / ASC files, see below for how instructions to generate these) into a single bundle.jar to upload them to OSSRH staging:

Code Block

language	bash

$ jar cvf bundle.jar *.pom *.jar *.asc

Then log into https://oss.sonatype.org/ with your JIRA username / password and choose "Staging Upload" on the left side.

Choose "Artifact Bundle" from the dropdown, and select your bundle.jar for upload.

After uploading, select "Staging Repositories" on the left side, and locate your bundle in the list.

To abort the process, you can choose "Drop" to delete your staged bundle.

Select the repository and choose "Close" at the top. This will run a set of checks to verify that the artifacts are of sufficient quality to upload to Maven Central.

You can see the list of checks by selecting the staging repository and viewing the "close" item of the "Activity" tab

Problems Closing?

If you artifact(s) fail the GPG signing stage, you may need to upload them to an accepted keyserver (it should list the keyservers that its checking, just pick any one and give it some time to propagate the change before trying again):

Code Block

language	bash

$ gpg --keyserver <KEYSERVER_URL> --send-keys <YOUR_KEY_ID_WHICH_WILL_BE_FAIRLY_LONG>

...

If your artifacts fail the sources or javadoc checks, make sure you have generated them as part of your build (ensure they each have an <executions> tag in your pom.xml). If they are third-party artifacts that are missing source or javadoc, see below.

pages/requirements.html

See https://maven.apache.org/guides/mini/guide-central-repository-upload.html

If you used OSSRH, you will then need to comment back on your Project JIRA ticket to enable sync to The Central Repository after promoting your first release for them

After that, any future releases that you promote from the staging repository will be automatically synced to 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>
            <!--

If you repository "closed" successfully, then you are now ready to begin testing the staged artifacts!

Testing a Closed Repository

Promote a Bundle

Release a Bundle

Automation

Insert snippet about Maven Release Plugin or Nexus Staging Maven Plugin, which supposedly helps to automate the above processes

Code Block

language	bash

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


			<!-- Maven ReleaseSources Plugin -->
			<plugin>
				<groupId>org.apache.maven.plugins</groupId>
				<artifactId>maven-releasesource-plugin</artifactId>
				<version>2<version>3.50.3<1</version>
				<configuration>
<executions>
					<execution>
						<mavenExecutorId>forked<id>attach-path<sources</mavenExecutorId>id>
						<useReleaseProfile>false</useReleaseProfile><phase>package</phase>
						<goals>
					<arguments>-Psonatype-oss-release</arguments>		<goal>jar</goal>
						</configuration>goals>
					</plugin>

execution>
				</executions>
			</plugin>
            <!-- More plugins... -->


          </plugins>
        </build>

Third-Party Dependencies

What do you do if one of your dependencies has not been uploaded to The Central Repository? All is not lost!

You could reach out to them to see if they are willing to perform the steps necessary to publish them, but it's unlikely that they will be open to this idea if it was not already in their plans, or if they don't use Maven at all..

If the project is open-source and accepts contributions, you could contribute a modified pom.xml allowing them to publish their artifacts to OSSRH or similar.

If you can obtain permission from the developers, they may allow you to publish it on their behalf:

...

DO NOT publish another developer's code without their permission!

...

If found, generate a JAR containing the source code (don't forget to include the LICENSE, if necessary):

Code Block

language	bash

jar -cvf indri-5.11-sources.jar *

...

If found, generate JavaDoc HTML from the source code and bundle it into a separate JAR (don't forget to include the LICENSE, if necessary):

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

...

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

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>

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

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

...

Bundle everything up and upload this bundle to the Staging repo in the same way as described above:

Code Block

language	bash

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

Central Sync Requirements

NOTE: Below I use OSSRH as an example, but this should work for any Accepted Hosting Repository.

OSSRH (and probably other approved repository hosts) will even sync your released artifacts with Maven Central on your behalf.

Sadly, this process did not seem to lift any of the strict requirements for the artifacts synced/

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

See https://maven.apache.org/guides/mini/guide-central-repository-upload.html

If you used OSSRH, you will then need to comment back on your Project JIRA ticket to enable sync to The Central Repository after promoting your first release for them

After that, any future releases that you promote from the staging repository will be automatically synced to 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.

To list existing keys:

Code Block

language	bash

$ gpg --list-keys
/Users/<USERNAME>/.gnupg/pubring.kbx
----------------------------------
pub   rsa2048 2017-05-05 [SC] [expires: 2019-05-05]
      <YOUR_KEY_ID_WHICH_WILL_BE_FAIRLY_LONG>
uid           [ultimate] Craig Willis (https://github.com/craig-willis) <willis8@illinois.edu>
uid           [ultimate] Garrick Sherman (https://github.com/gtsherman) <gsherma2@illinois.edu>
uid           [ultimate] Mike Lambert (https://github.com/bodom0015) <lambert8@illinois.edu>
sub   rsa2048 2017-05-05 [E] [expires: 2019-05-05]

Then execute the following command to upload your public key:

Code Block

language	bash

$ gpg --keyserver hkp://pool.sks-keyservers.net --send-keys <YOUR_KEY_ID_WHICH_WILL_BE_FAIRLY_LONG>

where <YOUR_KEY_ID_WHICH_WILL_BE_FAIRLY_LONG> is pulled from the output above

NOTE: You may need to share this public key with other keyservers, if your artifacts fail the Central Sync Checks for GPG signing due to a missing key

Manually Signing a Single File

To sign a file with your GPG key:

Code Block

language	bash

$ gpg -ab ir-utils-0.1.0.jar

NOTE: You will be asked to enter your GPG key's passphrase

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

Verifying GPG Signatures

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

Code Block

language	bash

$ gpg --verify target/ir-utils-0.1.0.jar.asc
gpg: assuming signed data in 'target/ir-utils-0.1.0.jar'
gpg: Signature made Thu Jun  1 21:21:16 2017 CDT
gpg:                using RSA key <YOUR_KEY_ID_WHICH_WILL_BE_FAIRLY_LONG>
gpg: Good signature from "Craig Willis (https://github.com/craig-willis) <willis8@illinois.edu>" [ultimate]
gpg:                 aka "Garrick Sherman (https://github.com/gtsherman) <gsherma2@illinois.edu>" [ultimate]
gpg:                 aka "Mike Lambert (https://github.com/bodom0015) <lambert8@illinois.edu>" [ultimate]

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

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

Code Block

language	bash

$ mvn clean package gpg:sign install:install deploy:deploy

This single command will:

...

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.

To list existing keys:

Code Block

language	bash

$ gpg --list-keys
/Users/<USERNAME>/.gnupg/pubring.kbx
----------------------------------
pub   rsa2048 2017-05-05 [SC] [expires: 2019-05-05]
      <YOUR_KEY_ID_WHICH_WILL_BE_FAIRLY_LONG>
uid           [ultimate] Craig Willis (https://github.com/craig-willis) <willis8@illinois.edu>
uid           [ultimate] Garrick Sherman (https://github.com/gtsherman) <gsherma2@illinois.edu>
uid           [ultimate] Mike Lambert (https://github.com/bodom0015) <lambert8@illinois.edu>
sub   rsa2048 2017-05-05 [E] [expires: 2019-05-05]

Then execute the following command to upload your public key:

Code Block

language	bash

$ gpg --keyserver hkp://pool.sks-keyservers.net --send-keys <YOUR_KEY_ID_WHICH_WILL_BE_FAIRLY_LONG>

where <YOUR_KEY_ID_WHICH_WILL_BE_FAIRLY_LONG> is pulled from the output above

NOTE: You may need to share this public key with other keyservers, if your artifacts fail the Central Sync Checks for GPG signing due to a missing key

Manually Signing a Single File

To sign a file with your GPG key:

Code Block

language	bash

$ gpg -ab ir-utils-0.1.0.jar

NOTE: You will be asked to enter your GPG key's passphrase

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

Verifying GPG Signatures

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

Code Block

language	bash

$ gpg --verify target/ir-utils-0.1.0.jar.asc
gpg: assuming signed data in 'target/ir-utils-0.1.0.jar'
gpg: Signature made Thu Jun  1 21:21:16 2017 CDT
gpg:                using RSA key <YOUR_KEY_ID_WHICH_WILL_BE_FAIRLY_LONG>
gpg: Good signature from "Craig Willis (https://github.com/craig-willis) <willis8@illinois.edu>" [ultimate]
gpg:                 aka "Garrick Sherman (https://github.com/gtsherman) <gsherma2@illinois.edu>" [ultimate]
gpg:                 aka "Mike Lambert (https://github.com/bodom0015) <lambert8@illinois.edu>" [ultimate]

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

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

Code Block

language	bash

$ mvn 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 (Expert)

See https://books.sonatype.com/nexus-book/reference/staging-repositories.html

At some point, you will likely want to assemble a release (non-SNAPSHOT) version of the code that people can be confident will not change out from under them suddenly. This is where releases come in - since they are unique and permanent, users can consume released artifacts confidently without fear of them changing in the future. without warning.

Bundle Your Artifacts

First, perform a full build of your project using the big command from above and the cd to where the build artifacts were output:

Code Block

language	bash

$ mvn clean package gpg:sign install:install deploy:deploy 
$ cd target/

NOTE: For complex project with multiple subprojects, it may be best to look into the Maven Bundle Plugin.

Bundle your build artifacts (JAR / POM / ASC files, see below for how instructions to generate these) into a single bundle.jar to upload them to OSSRH staging:

Code Block

language	bash

$ jar cvf bundle.jar *.pom *.jar *.asc

Upload Your Artifact Bundle

Then log into https://oss.sonatype.org/ with your JIRA username / password and choose "Staging Upload" on the left side.

Choose "Artifact Bundle" from the dropdown, and select your bundle.jar for upload.

After uploading, select "Staging Repositories" on the left side, and locate your bundle in the list.

To abort the process, you can choose "Drop" to delete your staged bundle.

Select the repository and choose "Close" at the top. This will run a set of checks to verify that the artifacts are of sufficient quality to upload to Maven Central.

You can see the list of checks by selecting the staging repository and viewing the "close" item of the "Activity" tab, and are examined in more details above (See "Central Sync Requirements")

Problems Closing?

If you artifact(s) fail the GPG signing stage, you may need to upload them to an accepted keyserver (it should list the keyservers that its checking, just pick any one and give it some time to propagate the change before trying again):
Code Block
language bash
$ gpg --keyserver <KEYSERVER_URL> --send-keys <YOUR_KEY_ID_WHICH_WILL_BE_FAIRLY_LONG>
If your artifacts fail the sources or javadoc checks, make sure you have generated them as part of your build (ensure they each have an <executions> tag in your pom.xml). If they are third-party artifacts that are missing source or javadoc, see below.

If you repository "closed" successfully, then you are now ready to begin testing the staged artifacts!

Testing a Closed Repository

Release the Bundle

Potential Plugins of interest

Insert snippets about:

Maven Bundle Plugin, which supposedly helps to automate the process of creating a bundle.jar for upload
Maven Release Plugin or Nexus Staging Maven Plugin, which supposedly helps to automate the process of uploading, closing, and promoting uploaded bundles

For example:

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>

Third-Party Dependencies

What do you do if one of your dependencies has not been uploaded to The Central Repository? All is not lost!

You could reach out to them to see if they are willing to perform the steps necessary to publish them, but it's unlikely that they will be open to this idea if it was not already in their plans, or if they don't use Maven at all..

If the project is open-source and accepts contributions, you could contribute a modified pom.xml allowing them to publish their artifacts to OSSRH or similar.

If you can obtain permission from the developers, they may allow you to publish it on their behalf:

First and foremost, ask for the developers' permission to publish their code, consult the license, etc
1. DO NOT publish another developer's code without their permission!
Locate the source code (if possible)
1. If found, generate a JAR containing the source code (don't forget to include the LICENSE, if necessary):
  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 (don't forget to include the LICENSE, if necessary):
  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
Locate compiled binaries (you can choose to download them, or build them yourself if you are able)

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>

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

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

Bundle everything up and upload this bundle to the Staging repo in the same way as described above:
Code Block
language bash
jar -cvf indri-5.11-bundle.jar *.jar *.pom *.asc

...

Page tree

Versions Compared

Old Version 16

New Version 17

Key

Central Sync Requirements (Expert)

Problems Closing?

Generating JavaDoc via Maven

Generating Sources via Maven

Testing a Closed Repository

Promote a Bundle

Release a Bundle

Automation

Third-Party Dependencies

Central Sync Requirements

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

Bringing It All Together

Signing Your Artifacts via Maven

Generate a Keypair

Upload to Keyserver

Manually Signing a Single File

Verifying GPG Signatures

Bringing It All Together

Staging a New Release (Expert)

Bundle Your Artifacts

Upload Your Artifact Bundle

Problems Closing?

Testing a Closed Repository

Release the Bundle

Potential Plugins of interest

Third-Party Dependencies

Page tree

Page History

Versions Compared

Old Version 16

New Version 17

Key

Central Sync Requirements (Expert)

Problems Closing?

Generating JavaDoc via Maven

Generating Sources via Maven

Testing a Closed Repository

Promote a Bundle

Release a Bundle

Automation

Third-Party Dependencies

Central Sync Requirements

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

Bringing It All Together

Signing Your Artifacts via Maven

Generate a Keypair

Upload to Keyserver

Manually Signing a Single File

Verifying GPG Signatures

Bringing It All Together

Staging a New Release (Expert)

Bundle Your Artifacts

Upload Your Artifact Bundle

Problems Closing?

Testing a Closed Repository

Release the Bundle

Potential Plugins of interest

Third-Party Dependencies