Introduction to the

Maven provides you with a central repository. When you build a Java project, you directly download the dependent JAR packages from maven’s central repository and package them locally.

Everyone knows there is a Maven repository, but few people have looked into where the Maven repository is, and whether it is possible to publish your own JAR packages to the central repository. Today I will introduce you to the use of Maven Central Repository and OSSRH.

Why use a central warehouse

The address of the Maven central repository is search.maven.org/#browse, and you can use this link to find the jar packages that are published by various open source organizations.

This central repository is Apache Maven, the default repository for SBT. It also supports Apache Ant/Ivy, Gradle and other build tools.

In a world of open-source software, where more and more people and businesses are willing to contribute their code on the Web, the Maven community has a central repository that makes it easy for anyone to share and use JARS.

Preparation for release to central warehouse

Publishing to the central repository requires permissions, so we need to register our project, which is artifacts ID, and specify where we want to publish the project.

Sonatype provides a tool called Open Source Software Repository Hosting (OSSRH) to help us easily publish projects to a central Repository. It is the primary way for project owners and contributors to publish their components to a central repository.

For GitHub groupId (io.github.username), as long as your project URL matches the requested groupId, it will be verified immediately.

For other domain names, you can use either of the following methods to verify domain names:

  1. TXT file authentication: Create a TXT file for OSSRH ticket number under the domain name for authentication.
  2. GitHub Redirect: Set your domain name to be redirected to the GitHub URL of the hosting project.

Using OSSRH

Sonatype OSSRH (OSS repository Repository) provides repository repository services for open source project binaries using Sonatype Nexus repository Manager. OSSRH uses Maven’s repository format. We can call snapshots of development versions of binaries, issue binaries in phases, upgrade binaries and synchronize them to a central repository.

Create a ticket with Sonatype

Sonatype use JIRA to management to create the request, so we need to first create a JIRA account, address: your account was created issues.sonatype.org/secure/Sign… And then use the account to create a Project ticket, create ticket address: issues.sonatype.org/secure/Crea…

Generally, the audit will be conducted within 2 working days.

Component requirements in the central repository

Unlike our own private warehouse, the format of the components in the central warehouse has certain requirements. We need to follow its format specification.

Provide Javadoc and source code

In addition to poM files, you need to provide javadoc files and source code files. The purpose is to facilitate direct access and use within the IDE.

The names of these files follow the naming conventions of the Maven repository format, using artifactId plus Version as the file name, and using Javadoc or Sources as the name distinction depending on the type, ending in JAR, for example:

< the groupId > com. Example. Applications < / groupId > < artifactId > example - application < / artifactId > < version > 1.4.7 < / version >Copy the code

The corresponding Javadoc file and source code file are as follows:

Example - application - 1.4.7 - sources. The jar example application - 1.4.7 - javadoc. JarCopy the code

If you do not have javadoc and source code files, such as a Scala project, you need to create a dummy file to pass verification.

Sign the file using GPG/PGP

All files need to be signed with GPG/PGP to generate a.asc file, such as the following file:

Example - application - 1.4.7. Pom example - application - 1.4.7. Jar example - application - 1.4.7 - sources. The jar Example - application - 1.4.7 - javadoc. JarCopy the code

Need to generate:

Example - application - 1.4.7. Pom. Asc example - application - 1.4.7. Jar. The asc example application - 1.4.7 - sources. The jar. The asc Example - application - 1.4.7 - javadoc. Jar. AscCopy the code

The Metadata file

Metadata files are poM files that need to be submitted. This is the Project Object Model file that Apache Maven uses to define projects and their builds. When building with other tools, you must assemble it and make sure it contains the following required information.

In addition to the required information, it is recommended to include the correct dependencies for your project so that the build tool can use this information to correctly resolve the delivery dependencies and does not require users to manually manage the dependencies.

  1. Project coordinate information, also known as GAV. Includes groupId, artifactId and Version, as follows:
< the groupId > com. Example. Applications < / groupId > < artifactId > example - application < / artifactId > < version > 1.4.7 < / version >Copy the code

In addition, if the project is not a JAR package, it also needs to include packaging information. Valid values include: JAR, WAR, EAR, POM, Maven-plugin, EJB, RAR, PAR, AAR, and apklib.

  1. Project name, description, and URL information:
<name>Example Application</name>
<description>A application used as an example on how to set up pushing 
  its components to the Central Repository.</description>
<url>http://www.example.com/example-application</url>
Copy the code

Variables can also be used to build project names:

<name>${project.groupId}:${project.artifactId}</name>
Copy the code
  1. The License information
<licenses> <license> <name>The Apache License, Version 2.0 < / name > < url > http://www.apache.org/licenses/LICENSE-2.0.txt < / url > < / license > < / licenses >Copy the code
  1. Developer Information
<developers>
    <developer>
      <name>Manfred Moser</name>
      <email>[email protected]</email>
      <organization>Sonatype</organization>
      <organizationUrl>http://www.sonatype.com</organizationUrl>
    </developer>
  </developers>
Copy the code
  1. SCM information

SCM is the address of your project. If you use SVN, you can write it like this:

<scm>
  <connection>scm:svn:http://subversion.example.com/svn/project/trunk/</connection>
  <developerConnection>scm:svn:https://subversion.example.com/svn/project/trunk/</developerConnection>
  <url>http://subversion.example.com/svn/project/trunk/</url>
</scm>
Copy the code

If you use Github, you can write:

<scm>
  <connection>scm:git:git://github.com/simpligility/ossrh-demo.git</connection>
  <developerConnection>scm:git:ssh://github.com:simpligility/ossrh-demo.git</developerConnection>
  <url>http://github.com/simpligility/ossrh-demo/tree/master</url>
</scm>
Copy the code

The deployment of

The purpose of deployment is to deploy the generated components to a local repository. There are many tools available. The most common one is Apache Maven, and other build tools such as Apache Ant, Gradle, SBT, etc.

Note that OSSRH has a maximum upload size of 1024MB for a single file. If you need to upload larger components, you need to contact Sonatype.

Upload it to the central warehouse

Once deployed locally, it can be uploaded to a central repository.

You can use the Nexus Staging Maven Plugin or Ant Tasks to upload from the command line. It can also be uploaded by accessing oss.sonatype.org/ directly from the browser.

Once published, components are published to the central repository within 10 minutes and searchable from the central repository within 2 hours.

Let’s use browser publishing as an example to see how this works.

First log in to oss.sonatype.org/ using the username and password created by JIRA.

Once logged in, you can see the Build Promotion option in the lower left corner. We select Staging Repositories to show the repository currently in the stage state.

The stage repository created during deployment has a name that starts with the project’s groupId (remove the dot), with dashes and four digits. For example. If your project groupId is com.example.applications, the staging configuration file name will start with comexampleApplications. The serial number starts at 1000 and increases as the deployment increases, for example: comexampleApplication-1010.

Select the staging repository, and the panel below the list displays more details about the repository. Alternatively, click the Close and Release buttons.

When the deployment is complete, the state changes to Open, and clicking Close triggers validation of the component. If validation is successful, you can click the Release button to deploy it to the central repository.

If you choose to deploy using the Nexus Staging Maven plug-in or Ant task, you can do so directly from the command line.

This article is available at www.flydean.com/04-maven-os…

The most popular interpretation, the most profound dry goods, the most concise tutorial, many tips you didn’t know waiting for you to discover!

Welcome to pay attention to my public number: “procedures those things”, understand technology, more understand you!