Recently, an open source project was released to the maven central repository, and I recorded the release process and the pits encountered.
Create an account
Sonatype uses jira to manage work orders. If we want to create a new work order, we first need to create an account. This account can also use sonatype's Nexus, and we finally publish it to the central repository through Nexus.
Open the link https://issues.sonatype.org/secure/Signup!default.jspa to sign up for an account
Create a ticket
After logging in to the jira management interface, click the Create button above to create a work order.
Project: Select Community Support - Open Source Project Repository Hosting
Type: Select New Project
Summary: Subject, required, Fill in
Description according to actual situation: Description, optional, Fill in
Attachment according to actual situation: Attachment, optional
Group Id: GroupId of the project , Consistent with the GroupId in pom.xml, required
Project URL: the url of the project, required, if the project code is on github, generally fill in the project's github url
SCM url: SMC (Software Configuration Management) is for software configuration management Meaning, if the project code is on github, fill in the download address of github, such as [email protected]:SpringCloud/spring-cloud-gray.git
Already Synced to Central: Whether it has been synchronized to the central repository, if no No is selected .
Then click Create to submit and wait for the staff to review it. At this time, the status of the work order is Open, and if there is no problem with the information provided, the status will change from open to resolved. Of course, due to the time difference, the reply will usually be received in the afternoon or evening.
During this process, the first response I received was asking me if I owned the domain name springcloud.cn, because the groupId filled in the ticket was cn.springcloud.
The second reply is when the state changes from Open to Resolved, indicating that the next step can be performed.
Configuration project pom.xml
The first is to introduce the oss-parent parent dependency in the pom.xml of the project, which can save some publishing configurations:
<parent>
<groupId>org.sonatype.oss</groupId>
<artifactId>oss-parent</artifactId>
<version>7</version>
</parent>
Then complete the license, scm, and developer information in the pom.
But this method is very embarrassing when there is already a parent dependency. It is recommended to use the second one below.
The second is to copy the configuration in oss-parent, and then modify it slightly, taking spring-cloud-grap as an example:
<groupId>cn.springcloud.gray</groupId>
<artifactId>spring-cloud-gray</artifactId>
<packaging>pom</packaging>
<version>1.0.0</version>
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>1.5.4.RELEASE</version>
</parent>
<modules>
...
</modules>
<licenses>
<license>
<name>The Apache Software License, Version 2.0</name>
<url>http://www.apache.org/licenses/LICENSE-2.0.txt</url>
<distribution>repo</distribution>
</license>
</licenses>
<scm>
<tag>master</tag>
<url>[email protected]:SpringCloud/spring-cloud-gray.git</url>
<connection>scm:git:[email protected]:SpringCloud/spring-cloud-gray.git</connection>
<developerConnection>scm:git:[email protected]:SpringCloud/spring-cloud-gray.git</developerConnection>
</scm>
<developers>
<developer>
<name>saleson</name>
<email>[email protected]</email>
<organization>Spring Cloud中国社区</organization>
</developer>
</developers>
<dependencyManagement>
...
</dependencyManagement>
<profiles>
<profile>
<id>sonatype-oss-release</id>
<build>
<plugins>
<!-- Source -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-source-plugin</artifactId>
<version>2.2.1</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>jar-no-fork</goal>
</goals>
</execution>
</executions>
</plugin>
<!-- Javadoc -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<version>2.9.1</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
</plugin>
<!-- GPG -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-gpg-plugin</artifactId>
<version>1.1</version>
<executions>
<execution>
<id>sign-artifacts</id>
<phase>verify</phase>
<goals>
<goal>sign</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
<distributionManagement>
<snapshotRepository>
<id>sonatype-nexus-snapshots</id>
<url>
https://oss.sonatype.org/content/repositories/snapshots
</url>
</snapshotRepository>
<repository>
<id>sonatype-nexus-staging</id>
<url>
https://oss.sonatype.org/service/local/staging/deploy/maven2
</url>
</repository>
</distributionManagement>
</profile>
</profiles>
Please refer to https://github.com/SpringCloud/spring-cloud-gray/blob/master/pom.xml
Configure maven setting.xml to add server
Open maven's settings.xml configuration file and configure sonatype account information
<servers>
<server>
<id>sonatype-nexus-snapshots</id>
<username>Sonatype 账号</username>
<password>Sonatype 密码</password>
</server>
<server>
<id>sonatype-nexus-staging</id>
<username>Sonatype 账号</username>
<password>Sonatype 密码</password>
</server>
</servers>
Note that server.id needs to correspond to snapshotRepository.id in project pom.xml.
Configure gpg-key
gpg-key is used for signature verification of code and binary packages. Windows system can be downloaded and installed through https://www.gpg4win.org/download.html , such as Mac installation:
Run the command to install gpg
brew install gpg
When using brew to install, there was also a situation where the installation failed due to permissions, but it could not be installed using sudo, then the chown command was required to empower.
After the installation is complete, run the command to generate the key
gpg --gen-key
The red boxes all require keyboard input, and the third one is a capital O.
Note that you will be asked to enter a password later. This password needs to be recorded, and it will take days to wait for mvn deploy .
After that, you will get the pub number, which is in the red box below.
Upload the pub number to the key verification library
gpg --keyserver hkp://keyserver.ubuntu.com:11371 --send-keys B72E74B6790AC40083CCB60A0D90C381F96365D0
Build to sonatype's Nexus
Enter the project directory and run the mvn command to publish
mvn clean deploy -P sonatype-oss-release -Darguments="gpg.passphrase=密钥密码"
If you created another maven setting.xml file, run a command similar to the following
mvn clean deploy -P sonatype-oss-release -Darguments="gpg.passphrase=密钥密码" --settings /dev_tools/apache-maven-3.3.9/conf/settings-oss.xml
If the execution fails with the following error:
gpg: signing failed: Inappropriate ioctl for device
This means that the gpg version you installed is relatively new and requires additional configuration. Create two configuration files in the gpg installation directory (~/.gnupg for mac): gpg.conf and gpg-agent.conf, respectively, add the following contents:
gpg .conf
use-agent
pinentry-mode loopback
gpg-agent.con
allow-loopback-pinentry
After saving, execute the above mvn command again. If there is still an error, there may be a problem with the maven configuration. Check whether there is a syntax error in the maven configuration, and whether the configured account and password have special characters that need to be escaped. For example, '&' needs to be converted as '&'. Also note that it must be the same machine that generates the key and executes the deploy command.
release
After all of the above are successfully executed, there should already be the components just released in nexus, visit https://oss.sonatype.org/#stagingRepositories (Build Promotion -> Staging Repositories on the left) to view, usually the last one, you can press time Discarded viewing, you can also search through the search box in the upper right corner.
If you want to log in, the account and jira (when creating a ticket) are the same.
At this time, the status should be open, select the component, click Close->Confirm on the top, and nexus will do some processing and verification. If the verification fails, you need to delete the component and upload it after modification.
If the verification is successful, select the component and click Release->Confirm at the top. After the release is successful, the status will become Released and then automatically deleted.
You can click Advanced Search on the left side of the page to view. If you can find the published module, it means that it has been successful.
Looking at the work order in jira again, there is one more comment in the system, which means that it will usually be published to the maven central repository within 10 minutes, but if it is updated to search.maven.org, it will take two hours.
References:
Remember to submit a dependency package to the maven central repository once