How to publish gradle project to Maven central repository

16/09/2023 /

Original link: https://scottyeung.top/2023/gradle-deploy-maven-central/

How to publish the products of the developed gradle project to Maven Central Repository so that everyone can use your results? I went through the process last week and published a simple project I wrote for clipboard operation. I found it a bit troublesome. The process is relatively long. Moreover, if you use gradle, the gradle update is too fast and the compatibility is too poor, causing online problems. The documents found are actually different. What’s even more difficult is that even the official gradle release teaching document provided by sonatype is inconsistent with the actual latest gradle8 version. Therefore, we can only refer to the process inside, and the details can only be relied on. Find out for yourself.

release nature

Project release essentially packages the project into a usable artifact, which contains compiled bytecode and a configuration pom file containing project-related information. These products can be uploaded to a hosting platform for public use, such as the Sonatype Nexus Repository , and eventually synced to the Central Repository. When you need to use dependencies, declare the dependency identifier groupId:artifactId:version, and the build tool Maven/gradle will automatically obtain the dependencies from these warehouses and use them. Therefore, there are actually two core operations for publishing:

  1. Projects packaged into products
  2. Upload products to the hosting platform

Release process

Here we take the warehouse published to sonatype as an example. This is an open source artifact hosting platform that everyone can use, and the products are all public.

The latest gradle 8.2 is used here.

Create ticket

If you want to publish a product to a public warehouse, you first need to register a JIRA account with sonatype, then submit an issue and create a ticket for the product that needs to be published. In this ticket, you need to fill in the basic information of the product to be released, including groupId, project address, and project code management address (SCM).

After filling in the ticket, sonatype will review the relevant information and confirm whether the user has ownership of the groupId used (that is, whether there is domain name control with the groupId reversed). For example, if I want to use my own domain name top.yeungyeah As the groupId, I will be asked to add a resolution to the dns of the domain name. In addition to these general domain names, you can also use the GitHub Page provided by GitHub as a domain name, such as io.github.username. The verification method for this is relatively simple, just create a GitHub repo. Therefore, the groupId when publishing needs to be considered and cannot be filled in randomly.

Improve the project

sonatype has certain quality requirements for the projects it publishes. Among them, in addition to the compiled jar package of the project, the source code and javadoc of the project must also be uploaded and published to the hosting platform. This requires additional configuration in gradle’s build configuration file build.gradle.kts .

 1 2 3 4
 
 java { withJavadocJar () withSourcesJar () }

In addition, the information contained in the final generated pom configuration file of the released project must also be complete. For example, the project’s developer information and open source license require additional configuration.

maven-publish

Some people may find it strange when seeing this, why use gradle, but they have been talking about Maven’s release, and the release is also released to Maven’s central warehouse. In fact, gradle can support many types of dependencies. In addition to maven, it can also support ivy. However, Maven is now more widely used, so dependencies in the maven warehouse are basically used (and gradle does not seem to have its own dependency format standard).

The latest gradle can use the maven-publish plug-in it provides to complete release-related functions instead of the previous maven plug-in. Many configurations mentioned in the above document are not available in this new maven-publish plug-in. ?

 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53
 
 plugins { .. . `maven - publish ` } publishing { publications { create < MavenPublication >( "maven" ) { // 自行替换产物描述信息groupId = "io.github.yeung66" artifactId = "clipboard-jvm" version = version from ( components [ "java" ]) pom { // 填充生成的POM 信息name . set ( "clipboard-jvm" ) description . set ( "A simple clipboard library for jvm." ) url . set ( "https://github.com/yeung66/clipboard-jvm" ) licenses { license { name . set ( "The Apache License, Version 2.0" ) url . set ( "http://www.apache.org/licenses/LICENSE-2.0.txt" ) } } developers { developer { id . set ( "yeung66" ) name . set ( "YeungYeah" ) email . set ( "[email protected]" ) } } scm { connection . set ( "scm:git:git://github.com/yeung66/clipboard-jvm.git" ) developerConnection . set ( "scm:git:ssh://github.com/yeung66/clipboard-jvm.git" ) url . set ( "https://github.com/yeung66/clipboard-jvm" ) } } } } repositories { maven { name = "OSSRH" url = URI . create ( "https://s01.oss.sonatype.org/service/local/staging/deploy/maven2/" ) credentials { username = project . properties [ "ossrhUsername" ] as String password = project . properties [ "ossrhPassword" ] as String } } } }

The account password can be placed in gradle.properties in the user directory to prevent leakage.

signing

After generating the product, you need to sign the generated product once so that the hosting platform can ensure that the upload is completed by yourself and ensure the reliability of the product. To sign a release product, you need to generate your own key first and use the direct private key file to sign it. Then upload the public key to the public key server for the hosting platform to obtain the public key verification signature.

Specific steps are as follows

  1. First use gpg to generate your own key, please refer to this document by Ruan Yifeng
  2. Based on the key generated above, obtain the path of the private key, use the password of the private key, the keyId of the public key, and fill in the gradle.properties file. For the sake of security and not leaking personal information, generally this kind of sensitive information can be placed in the configuration file in the user directory rather than in the project. This can better avoid being leaked when the code repository is uploaded to GitHub. 
    •  signing.keyId= #The last 8 symbols of the keyId signing.password= #passphrase used to protect your private key signing.secretKeyRingFile= #absolute path to the secret key ring file containing your private key
    • (Since gpg 2.1, you need to export the keys with command gpg –keyring secring.gpg –export-secret-keys > ~/.gnupg/secring.gpg).
  3. Upload the public key to the public key server
  4. Add the signing plug-in to the build problem and configure it 
     plugins { ... signing } signing { sign(publishing.publications["maven"]) }

After the above configuration is performed, the build product will be automatically signed when executing the build release task.

Execute release

Just execute the release task of gradle directly

If the execution goes smoothly, the project will package the compiled product, sign it, and then upload it to the hosting platform. At this time, a release can be made in the hosting platform .

Find the newly released product in the staging repositories. After checking that the uploaded file is correct, click the close button to automatically advance to the inspection stage to check whether the released product meets the standards. The inspection here includes the quality inspection mentioned above. Information check. After passing the inspection, an email reminder will be sent, and then you can click the release button to officially release the product. After release, the product will be synchronized to the Maven Central warehouse and can be queried in mvnrepository or sonatype central .
However, it seems that this staging step can also be automated through plug-ins . Estimation can be simpler if it can be automated.

At this point, the gradle project can be successfully published to the Maven Central warehouse for everyone to use.

This article is reproduced from: https://scottyeung.top/2023/gradle-deploy-maven-central/
This site is only for collection, and the copyright belongs to the original author.