跳至主要内容

Deploy to Maven Central

Deploy to Maven Central

Recently, we need to deploy some jar to maven for open source reason, so we through some trial and errors finally make it. This blog is for future reader for review.

Registration

Introduction to Sonatype OSSRH

Sonatype OSSRH uses Nexus to provide deployment service for open source project, and this repo is called maven central, in which OSSRH all us to submit and download binary jar.

Registration

  • Create an account of JIRA
  • Create a new issue about your deploy request

Notice:

  • Only when this issue’s state change to RESOLVED, we can start to deploy jar;
  • If we deploy on behalf of yourself, we should be careful about groupId: e.g. our project is put on github called syncer, so groupId can be com.github.zzt93;

Update POM

After the registration and issue resolved, we need to add more info in pom to do the deployment: name, description, url, groupId, artifactId, version, license, developers, scm

<name>${project.groupId}:${project.artifactId}</name>
<url>https://github.com/0604hx/nerve-tools</url>
<description></description>

<licenses>
    <license>
        <name>The Apache License, Version 2.0</name>
        <url>http://www.apache.org/licenses/LICENSE-2.0.txt</url>
    </license>
</licenses>
<developers>
    <developer>
        <name>0604hx</name>
        <email>zxingming@foxmail.com</email>
        <roles>
            <role>developer</role>
        </roles>
        <timezone>+8</timezone>
    </developer>
</developers>
<scm>
    <connection>scm:git:https://github.com/0604hx/nerve-`tools.git</connection>
    <developerConnection>scm:git:https://github.com/0604hx/nerve-tools.git</developerConnection>
    <url>https://github.com/0604hx/nerve-tools</url>
    <tag>v${project.version}</tag>
</scm>

Then, add distributionManagement:

<distributionManagement>
    <snapshotRepository>
        <id>ossrh</id>
        <url>https://oss.sonatype.org/content/repositories/snapshots</url>
    </snapshotRepository>
    <repository>
        <id>ossrh</id>
        <name>Maven Central Staging Repository</name>
        <url>https://oss.sonatype.org/service/local/staging/deploy/maven2/</url>
    </repository>
</distributionManagement>

Then related plugins: staging for release, add javadoc, add source, use gpg to sign

<plugins>
    <plugin>
        <groupId>org.sonatype.plugins</groupId>
        <artifactId>nexus-staging-maven-plugin</artifactId>
        <version>1.6.3</version>
        <extensions>true</extensions>
        <configuration>
            <serverId>ossrh</serverId>
            <nexusUrl>https://oss.sonatype.org/</nexusUrl>
            <autoReleaseAfterClose>false</autoReleaseAfterClose>
        </configuration>
    </plugin>
    <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-javadoc-plugin</artifactId>
        <version>2.10.3</version>
        <executions>
            <execution>
                <id>attach-javadocs</id>
                <goals>
                    <goal>jar</goal>
                </goals>
            </execution>
        </executions>
    </plugin>
    <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-source-plugin</artifactId>
        <executions>
            <execution>
                <id>attach-sources</id>
                <goals>
                    <goal>jar-no-fork</goal>
                </goals>
            </execution>
        </executions>
    </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>
</plugins>

Generate & Send Key

Since other people need our public key to verify our jars, we need to distribute our public key to a key server:

gpg --gen-key
gpg --keyserver http://keyserver.ubuntu.com:11371/ --send-keys KEY_ID

If you met the following error when signing jar file:

signing failed: Inappropriate ioctl for device

Here gives the solution:

export GPG_TTY=$(tty)

Update setting.xml

Add account & password in OSSRH, add profile of gpg for sign

    <server>
      <id>ossrh</id>
      <username>your-jira-id</username>
      <password>your-jira-pwd</password>
    </server>

...

    <profile>
      <id>ossrh</id>
      <activation>
        <activeByDefault>true</activeByDefault>
      </activation>
      <properties>
        <gpg.executable>gpg2</gpg.executable>
        <gpg.passphrase>the_pass_phrase</gpg.passphrase>
      </properties>
    </profile>

Deploy

mvn deploy -Dmaven.test.skip=true -e

No secret key

If maven compile that:

gpg: no default secret key: No secret key

it means that the phase of [Generate Key] failed, no secret key is not found.

No public key:Key with id

If the following error shows:

No public key:Key with id

It means that the command gpg --send-keys xx failed, try other key servers in the list of trying one instead.

Release

When last step succeeds, we have already upload our release (non-snapshot) artifacts to the remote repo, but we actually only upload it to a staging repo:

<snapshotRepository>
    <id>ossrh</id>
    <url>https://oss.sonatype.org/content/repositories/snapshots</url>
</snapshotRepository>
<repository>
    <id>ossrh</id>
    <name>Maven Central Staging Repository</name>
    <url>https://oss.sonatype.org/service/local/staging/deploy/maven2/</url>
</repository>

In order to release it, we need:

After you successfully release, your component will be published to Central, typically within 10 minutes, though updates to search.maven.org can take up to two hours.

On the other hands, our snapshot artifact is no need to have above release operation, we can access it if we have snapshot repo in our pom:

<repository>  
    <id>ossrh</id>  
    <url>https://oss.sonatype.org/content/repositories/snapshots</url>  
</repository>

Ref

Written with StackEdit.

评论

此博客中的热门博文

Spring Boot: Customize Environment

Spring Boot: Customize Environment Environment variable is a very commonly used feature in daily programming: used in init script used in startup configuration used by logging etc In Spring Boot, all environment variables are a part of properties in Spring context and managed by Environment abstraction. Because Spring Boot can handle the parse of configuration files, when we want to implement a project which uses yml file as a separate config file, we choose the Spring Boot. The following is the problems we met when we implementing the parse of yml file and it is recorded for future reader. Bind to Class Property values can be injected directly into your beans using the @Value annotation, accessed via Spring’s Environment abstraction or bound to structured objects via @ConfigurationProperties. As the document says, there exists three ways to access properties in *.properties or *.yml : @Value : access single value Environment : can access multi...

LevelDB Source Reading (1): Structure

LevelDB Source Reading (1): Structure LevelDB “is an open source on-disk key-value store.” After I read some documents, I have some basic understanding of LevelDB. So I come up with some questions about structure of LevelDB to answer when reading the source code. Structure Log File: repair/recover db A log file (*.log) stores a sequence of recent updates. Each update is appended to the current log file. The log file contents are a sequence of 32KB blocks. The only exception is that the tail of the file may contain a partial block. Block format: Each block consists of a sequence of records: block := record* trailer? record := checksum: uint32 // crc32c of type and data[] ; little-endian length: uint16 // little-endian type: uint8 // One of FULL, FIRST, MIDDLE, LAST data: uint8[length] // data is LengthPrefixedSlice with type from batch data definition in Block : data: also named `writeBatch` in levelDB // WriteBatch header has an 8-byte ...

Install `nicstat`on Linux

Introduction nicstat is to network interfaces as “iostat” is to disks, or “prstat” is to processes. It is designed as a much better version of “netstat -i”. Its differences include: Reports bytes in & out as well as packets. Normalizes these values to per-second rates. Reports on all interfaces (while iterating) Reports Utilization (rough calculation as of now) Reports Saturation (also rough) Prefixes statistics with the current time With the help from nicstat , we can identify whether distributed Java application is saturating the network by view the utilization percentage of specific interface. Download Sourceforge Download Link Build Following the guide of README.txt, we build like following: $ mv Makefile.Linux Makefile $ make mv nicstat `./nicstat.sh --bin-name` Install $ make install gcc -O3 -m32 nicstat.c -o nicstat In file included from /usr/include/features.h: 392 : 0 , from /usr/include/stdio.h: 27 , from nicsta...