Publishing an artifact to Maven Central via Sonatype OSS Repository Hosting Service

At the writing of this article I was led by some fragmentation of sources of information on such
important, in my opinion, the topic, as the publication of their artifacts in the Maven Central. Of course should
pay tribute to the staff Sonatype: their official guide (link at the end of the article) quite fully
describes the whole process. But there are not some unobtrusive subtleties in it (like the problem of storing
passwords), and he himself looks a bit sloppy. I did not find any resources in Russian on this topic.
principle. For me personally, this is not scary, but it can stop many.

Probably most Java programmers know what Maven Central is. For those who do not know:
Maven Central is a huge library repository for the JVM platform. Anyone can post
There library, if its license allows public distribution. After that this library
can be specified as a dependency in the project's build system, such as Maven. Then when building the project
This system will automatically download the library and compile your project with its use. On my
look, it is the presence of Maven Central is one of the key reasons (if not the most important) success
Java as a platform. I do not know more than a single repository, which is compared to Central in the number
artifacts and usability; the only thing that comes to mind is CPAN, Comprehensive
Perl Archive Network, or Haskell's Cabal, but it's still not quite right.
')
Anyone can upload to the Central library. You can even upload not your own libraries, but
strangers that no one has ever been able to put there, but only if the library license allows
such a spread. A week ago I wrote one library and decided to post it in Central. how
it turned out to be a somewhat nontrivial process at first glance, although in general nothing supercomplex
it is not.

Initially, as far as I understood from the remnants of the documentation on this topic, artifacts in Maven Central
taken by their server using rsync. However, this was considered an unsuccessful decision, and now Maven
Central is replenished from several large trusted repositories of artifacts. That which us
interests, called Sonatype OSS Repository Hosting Service . This is a Sonatype project,
giving anyone the opportunity to share their library. Maven servers
Central syncs regularly with OSSRH, and those artifacts that the user marks as
ready for release are uploaded to the central repository.

In short, the procedure for uploading your artifact to Central looks like this: you need to register on
Sonatype JIRA and leave a ticket to open the repository; then when the repository is opened, you will need to
load artifacts into it (manually or using a special configuration of the assembly system), and then
indicate that these artifacts should be poured into Central.

Sonatype Repositories provides two, Snapshots and Staging. Snapshots repository is designed to
so-called snapshots , in fact, builds directly from the main development branch to
version control system. Staging repository is intended for releases of artifacts - those versions
which will no longer change. Staging is so called because the artifacts from it after checking
health needs to "promote" (promote) in Maven Central. After a while Maven Central
syncs with Sonatype OSSRH, and your artifacts will appear in Central.

Consider all the steps on the items.

Create a ticket on Sonatype JIRA

The first step is to open the repository, into which artifacts will be downloaded for synchronization with
Central. This is done through the ticket system in Sonatype JIRA. Link: http://issues.sonatype.org/ .

First you need to register there. On the page that opens, click the link below Sign Up . A standard registration form will open. Complete and submit it. It should be noted, however, that
in the Full Name field you need to enter exactly the full name, like “Vasiliy Pupkin”, in two words through
space. The official guide states that this is due to problems with the integration between JIRA and something
named Crowd.

After filling and sending the form, you will automatically be logged in to the system. On the main
You can find the following link in the list of projects on the left:
https://issues.sonatype.org/browse/OSSRH . This is the section in which you need to create an opening ticket.
repository To create a ticket, click the New Project button. Fields should be filled like this:

Important point: group id, I have indicated a common - org.bitbucket.googolplex , and not
org.bitbucket.googolplex.devourer . This is done with an eye to the future: suddenly you want
publish another one of your project? In this case, you will not have to start additional tickets,
the global prefix for the repositories will already belong to you. Basically, people who work
over these tickets are quite adequate and experienced, so they can change the group id for you
more general self.

The official statement says that group id should be chosen in such a way that it means
domain controlled by you. This could be your site or section on a version control service like
Github or Bitbucket (like mine, in the example above). Before you create a repository for you,
the package name will be checked and written if there are any problems with it (for example, the corresponding site
does not belong to you).

After a while, a Sonatype employee will create a set of repositories for you and close the ticket. To me
lucky, my ticket was closed almost immediately after its creation. After that you can download
artifacts in the staging repository, and from there they can be promoted (promote) in Central. However before
How to load artifacts into the repository, you need to create them. For this you need the right
how to configure the maven, i.e. your project’s pom.xml file and possibly the system file
settings mavena settings.xml .

We create and prepare artifacts for unloading.

Now there are many build systems that can create standard mavenovo artifacts: Maven,
Buildr, SBT, Gradle, Leiningen and others. The instructions below are correct for Maven version 3. In an article on the wiki
Sonatype (link at the end of this article) has instructions for using other build systems.

The essence of the concept of “artifact” in the context of maven is very simple - this is just a regular jar file with
additional meta information. This artifact description is the so-called POM , Project Object.
Model represented by pom.xml file. I will not describe the format in full here, but only indicate
those parts of the POM that must be available to successfully download the artifact to Maven Central.

So, according to the official Sonatype documentation, the pom.xml should be present in pom.xml
sections:

, packaging jar , , -sources.jar -javadoc.jar . , , Scala, -sources.jar -javadoc.jar README- . , pom.xml , , . GnuPG, hkp://pool.sks-keyservers.net/ . GnuPG . pom.xml :
```
 <?xml version="1.0" encoding="UTF-8"?> <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>org.bitbucket.googolplex.devourer</groupId> <artifactId>devourer</artifactId> <version>0.1-SNAPSHOT</version> <packaging>jar</packaging> <name>Devourer</name> <description>Feeds on XML and produces objects</description> <url>http://bitbucket.org/googolplex/devourer</url> <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> <url>https://bitbucket.org/googolplex/devourer</url> <connection>scm:hg:https://bitbucket.org/googolplex/devourer</connection> </scm> <developers> <developer> <id>owner</id> <name>Vladimir Matveev</name> <email>dpx.infinity@gmail.com</email> <timezone>UTC+4</timezone> </developer> </developers> <dependencies> <dependency> <groupId>com.google.guava</groupId> <artifactId>guava</artifactId> <version>14.0-rc3</version> </dependency> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>4.10</version> <scope>test</scope> </dependency> </dependencies> </project> 
```
In principle, such pom.xml enough to load artifacts into the repository. Artifacts then
you will need to manually sign and manually upload them to the staging repository. However, maven was
designed to automate routine operations, and deploy artifacts to the repository
contained among them.

In order for the maven to download the artifacts into the repository and sign them, you need to add and configure
several plugins. However, before we set up GnuPG.

Configuring GnuPG to sign artifacts

GnuPG (GNU Privacy Guard) is an alternative implementation of the well-known software package for
PGP cryptography, fully compatible with the OpenPGP standard. Using GnuPG, you can create keys
for asymmetric and symmetric data encryption, and also to encrypt itself by many
algorithms. You can also sign data using GnuPG. This functionality is interesting to us.

Installing GnuPG is system dependent. In Linux, everything is very simple. Normally GnuPG comes in
standard repository and, quite likely, you already have it installed. If not, then you need to ask
package manager install it. In Archlinux, for example, this is done like this:
```
 $ sudo pacman -S gnupg
```
After installation, gpg will appear in the PATH . This is enough for maven.

Under Windows, installation is a bit more complicated. GnuPG provides binaries compiled for Windows, but there
there are only relatively old versions. In my opinion, the best option would be to use
gpg4win This is a GnuPG build under Windows with several additional programs, for example,
graphical key manager. For mavena, this is, in general, not necessary, but it may be useful to you. Site
gpg4win: http://www.gpg4win.org/ . There you can find an installer. When installing it should automatically
add to the system PATH path to the directory where gpg.exe is gpg.exe - what we need.

After installing GnuPG, we open the terminal and write in it:
```
 $ gpg - gen-key
```
GnuPG will prompt you for the following parameters:
1. Key algorithm - by default you will most likely have RSA and RSA , this is the best option.
2. Key size - the default should be 2048 bits, which is quite enough.
3. Key expiration - by default, the key is valid indefinitely; you can install
  Validity as an additional measure of security. After the expiration of the key, you can
  will renew if you have not forgotten the password to the key.
4. Name and E-Mail - your name and e-mail. It is advisable to specify the real ones here.
  values.
5. Comment - optional field (I do not know why it is needed), leave it blank.
6. Password - here you need to enter a password to protect the private key. Depending on the system
  you will be prompted to enter your password in different ways: a graphical window may appear (gpg4win or GnuPG,
  launched from under the Linux shell), or you will be prompted to enter a password in
  the terminal. This password will be requested whenever you need to use a private
  key, for example, to sign or update the key's validity time.
After all these parameters have been entered, GnuPG will ask you to use the mouse or type something on
keyboard to get entropy for key generation. Be careful with this if you work.
on the server via SSH: GnuPG can hang for a very long time waiting for entropy from devices, and through
SSH mouse or keyboard do not pull.

Then GnuPG will report successful key generation and print their fingerprint. Check availability again
The key can be entered by typing gpg --list-keys :
```
 $ gpg --list-keys
 C: /Users/vpupkin/AppData/Roaming/gnupg/pubring.gpg
 -------------------------------------------------- -
 pub 2048R / 1A89FE67 2013-02-26
 uid Vasiliy Pupkin <vp@example.com>
 sub 2048R / D9725D51 2013-02-26
```
Now you can sign files (and indeed any data) with GnuPG. One more left
moment: you need to upload your public key to the key server hkp://pool.sks-keyservers.net . For
you need to enter the following command:
```
 $ gpg --keyserver hkp: //pool.sks-keyservers.net --send-keys 1A89FE67
```
The argument to the parameter --send-keys specified short imprint key, which can be taken from the output
gpg --list-keys commands After a while, GnuPG will shut down, which will mean that the key
published

Now, if you do not want to sign artifacts and upload them into the repository manually, you need
set up a maven so he does it for you.

Configuring mavena to automatically sign and download artifacts in snapshot and staging repositories

Most of the maven configuration is done from pom.xml configuring the appropriate plugins. But,
part of the configuration should be added to settings.xml , the maven's system settings file. Usually this
the file is in $HOME/.m2/settings.xml ( %HOME%\.m2\settings.xml on Windows) and is intended for
user-specific settings, such as passwords or repositories.

First you need to make your pom.xml inherit from the artifact provided by Sonatype
specifically to simplify the upload of artifacts to them on the server. To do this, add the following
Piece in your pom.xml :
```
 <parent> <groupId>org.sonatype.oss</groupId> <artifactId>oss-parent</artifactId> <version>7</version> </parent> 
```
As far as I understand (I haven't tried it myself yet), if you are going to load a complex multi-module
a project that already uses POM inheritance, you need to make the oss-parent ancestor of all those
artifacts that have no ancestors, that is, the roots of all the hierarchies in the project. Usually such a root
alone, but still.

Here is a list of required plugins:
- maven-source-plugin
- maven-javadoc-plugin
- maven-gpg-plugin
You also need a maven-release-plugin , but it is added automatically with the desired configuration via
inheritance from oss-parent .

The simplest is to configure the maven-source-plugin and maven-javadoc-plugin . Just add
The following sections in pom.xml :
```
 <build> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-source-plugin</artifactId> <version>2.2.1</version> <executions> <execution> <id>attach-sources</id> <phase>package</phase> <goals> <goal>jar</goal> </goals> </execution> </executions> </plugin> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-javadoc-plugin</artifactId> <version>2.9</version> <executions> <execution> <id>attach-javadocs</id> <phase>package</phase> <goals> <goal>jar</goal> </goals> </execution> </executions> </plugin> </plugins> </build> 
```
Here we indicated that during the package life cycle phase, jar files with source codes should be created and
documentation. The remaining plugins, maven-release-plugin and maven-gpg-plugin , automatically
pick up these generated artifacts, no additional configuration is required.

Next, configure the plugin for the release of artifacts, maven-release-plugin . As I said, this plugin
automatically configured in the artifact oss-parent , from which our
artifacts. Also in this artifact are configured repository addresses. maven-release-plugin will be
use them to download artifacts. But, obviously, just like that, load artifacts into
the repository is impossible, you need to identify yourself, that is, specify the name and password.

The name and password are specified in settings.xml . The final version of this file should look like
like that:
```
 <settings xmlns="http://maven.apache.org/SETTINGS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd"> <servers> <server> <id>sonatype-nexus-snapshots</id> <username>vpupkin</username> <password>password</password> </server> <server> <id>sonatype-nexus-staging</id> <username>vpupkin</username> <password>password</password> </server> <server> <id>bitbucket.org</id> <username>vpupkin</username> <password>password</password> </server> </servers> </settings> 
```
The identifiers of the repositories sonatype-nexus-snapshots and sonatype-nexus-staging defined in
oss-parent , and maven will automatically take the name and password from the corresponding settings.xml sections
to load artifacts into these repositories. The name and password here should be those that were
Used when registering with Sonatype JIRA.

I also indicated here a server with a bitbucket.org identifier. This is needed for the plugin.
maven-scm-plugin , which is used by the maven-release-plugin to create in the system
version control tags corresponding to the release. In order for this to work, you need to specify
additional address in the block pom.xml :pom.xml :
```
 <scm> <url>https://bitbucket.org/googolplex/devourer</url> <connection>scm:hg:https://bitbucket.org/googolplex/devourer</connection> <developerConnection>scm:hg:https://bitbucket.org/googolplex/devourer</developerConnection> </scm> 
```
The new address is listed in the developerConnection element. Here it matches the address in connection ,
but, generally speaking, they can be different: connection means the address for read-only access to the code, and
developerConnection - read-write. Just for him we added a login and password to
bitbucket.org in settings.xml . maven-scm-plugin itself recognizes that this login and password
refer to the server specified in . maven-scm-plugin PATH . , hg hg.exe . maven-release-plugin VCS . : , Windows , PATH. maven-gpg-plugin . , , , Maven Central. , . , , maven-release-plugin , . , . , . pom.xml , settings.xml . maven-gpg-plugin pom.xml :. maven-scm-plugin PATH . , hg hg.exe . maven-release-plugin VCS . : , Windows , PATH. maven-gpg-plugin . , , , Maven Central. , . , , maven-release-plugin , . , . , . pom.xml , settings.xml . maven-gpg-plugin pom.xml :
```
 <?xml version="1.0" encoding="UTF-8"?> <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"> ... <profiles> <profile> <id>sign-artifacts</id> <activation> <property> <name>performRelease</name> <value>true</value> </property> </activation> <build> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-gpg-plugin</artifactId> <version>1.4</version> <configuration> <passphrase>${gpg.passphrase}</passphrase> </configuration> <executions> <execution> <id>sign-artifacts</id> <phase>verify</phase> <goals> <goal>sign</goal> </goals> </execution> </executions> </plugin> </plugins> </build> </profile> </profiles> </project> 
```
Here a new profile, sign-artifacts , is announced, and it is indicated that it should be activated
when the system property performRelease is true . This property sets
maven-release-plugin when its release command is launched. The profile is configured
maven-gpg-plugin : it should be launched upon reaching the verify life cycle verify . Also
Our password for the GPG key is passed to the plugin.

This password is passed through the property gpg.passphrase . It is clear that keep the password private
the key in pom.xml itself pom.xml somewhat unreasonable. Instead, configure it in settings.xml . For
This will create another profile, but inside the settings.xml . It will look like this:
```
 <settings xmlns="http://maven.apache.org/SETTINGS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd"> ... <profiles> <profile> <id>gpg-passphrase</id> <activation> <activeByDefault>true</activeByDefault> </activation> <properties> <gpg.passphrase>passphrase</gpg.passphrase> </properties> </profile> </profiles> </settings> 
```
Here we indicate that in the profile you need to define the property gpg.passphrase with a value equal to
password to the key. This value will be substituted in the appropriate place in the configuration.
maven-gpg-plugin In the conditions of activation is
```
  because the password to the key 

 not only during the release process itself, but also in the process of preparing for it, but for 

 no distinctive properties of this are installed by any plugins. 



  Uploading artifacts to the repository 




 In general, this is all that needs to be done in order for maven to be able to load artifacts into the repository.  If now 

 You run this command in the project root: 


 $ mvn deploy
```
then after a while the current version of your artifacts will be loaded into the snapshot repository.

The snapshots repository can be accessed from outside, for example, to use snapshot versions.
artifact. It is possible to do this, for example, at this address:
https://oss.sonatype.org/content/groups/staging . However, the repository for this link is important for another
the reason. It includes not only snapshots and releases, but also so-called. staged version
artifacts. In fact, these are release versions that are not yet synchronized. Maven
Central. Stage space is needed for the last check that everything is in order with your artifacts. Thats
there is, before releasing an artifact in Central, it’s worth checking that, for example, a project that uses your
artifact, compiled normally, if it will depend on the new release version. If they arise
Any problems, staged-artifact can be removed and re-created. As soon as all problems
resolved, a staged artifact can be "promoted" in Maven Central. From now on, change it already
will be impossible.

Let's take a closer look at how the artifact download to the staging repository looks like and what to do.
to "promote" an artifact in Central.

Since the project is already configured to release artifacts, it suffices to execute two commands:
```
 $ mvn release: prepare
 ...
 $ mvn release: perform
 ...
```
The first team prepares the release. More specifically, it does the following:
- checks that there are no uncommitted changes in the source tree;
- checks that all artifacts have no dependencies on the snapshot version of other artifacts;
- changes the version of all artifacts from x-SNAPSHOT to the one you specify;
- modifies the version control information in pom.xml to match the new path
  in the repository for the new release (relevant for those VCS, in which there is no separate concept of tags,
  such as SVN);
- runs automatic tests with modified pom.xml to check that nothing is broken;
- commit changed pom.xml ;
- creates a tag in the repository for the new version, asking you for the name of the tag;
- updates the version in pom.xml on y-SNAPSHOT (this plugin will also ask you);
- commit changed pom.xml .
Thus, after running mvn release:prepare in the repository, two commit commit (the first with
updating the current snapshot version to the release version, and the second from the release version to the new snapshot version; and
one tag (which will indicate the commit where the release version is present).

In other words, mvn release:prepare creates a "release point" in the repository, fixing that state
project, which will fall into Central.

Now you need to load the artifact into the repository. To do this, use the second command, mvn release:perform . This command extorts the release version tag from the repository and collects it with the command
like mvn site-deploy . The mvn site-deploy command under the conditions of this project configuration, which we
done, upload the artifact to the staging repository.

Obviously, mvn release:perform should from somewhere take the name of the tag that needs to be downloaded. She is
can take a tag either from the release.properties file, which is created by the mvn release:prepare command, or from the command line. After successfully uploading the artifact and related files
in the repository, release:perform will delete the extra files created by release:prepare .

Warning: when using such VCS, in which the concept of the tag is not related to the file system
(for example, this is Mercurial and Git), via the command line specify the name of the tag, unfortunately,
can not. I didn’t find a way to specify a tag for mvn release:perform , if it wasn’t
done mvn release:prepare . If someone tells you how to do this, I will be very grateful.

Thus, after these commands are executed, your artifacts will be uploaded to the staging repository. Their
can be seen through the web interface of the Sonatype Nexus repository management system on
https://oss.sonatype.org/ . In the upper right corner of the link Log In you need to log in with the
the username and password you chose when registering with JIRA. After that, the left in the list will appear
Build Promotion group, and in it three links. The one we need is called Staging Repositories . By
clicking it in the central window will open a list of staging repositories, that is, temporary storage
for artifacts in the staging state. The official documentation provides screenshots of the window in which
, , . ,
- :

JIRA, , ,
.

. , Closed ,
Open . staging- — Open Closed .
Open . Closed
, Close . Nexus ,
, Maven Central:
, pom.xml .. - ,
Nexus , .
Closed , ;
Maven Central.
staging-: https://oss.sonatype.org/content/groups/staging . ,
, "" Maven Central.

, Central,
staging- Release .
staging- .
Sonatype OSSRH: https://oss.sonatype.org/content/groups/public . ,
Maven Central, .

Maven Central ,
Sonatype JIRA , "" ,
Maven Central:

Sonatype ( :
, ; , JIRA
— 12 ), .
Maven Central. Congratulations! :)

.
, , staging- ""
Maven Central .

settings.xml

, ,
settings.xml . : —
. , .
.

:
http://maven.apache.org/guides/mini/guide-encryption.html . ,
.
1. -:
```
$ mvn --encrypt-master-password your-password
```
  . .
  , , :
```
{FshtxgrHbMoH+X+v4cwYL9t9QgtwTgoLmfiV6LkPkvg=}
```
  $HOME/.m2/settings-security.xml , :
```
 <settingsSecurity> <master>{jSMOWnoPFgsHVpMvz5VrIt5kRbzGpI8u+9EF1iFQyJQ=}</master> </settingsSecurity> 
```
2. . :
```
$ mvn --encrypt-password your-password
```
  . :
```
{tly+tTyx46MHPhht/SryJw8+x4n4oWfzgAPZ/B+KFoc=}
```
  settings.xml :
```
 <settings> ... <servers> ... <server> <id>my.server</id> <username>foo</username> <password>{tly+tTyx46MHPhht/SryJw8+x4n4oWfzgAPZ/B+KFoc=}</password> </server> ... </servers> ... </settings> 
```
  , : maven-deploy-plugin , maven-scm-plugin .. , : . . , - . , -.
  
  , settings.xml
  -. settings-security.xml -
  , settings.xml .
  - , settings-security.xml -
  , , , $HOME/.m2/settings-security.xml ,
  , :
```
 <settingsSecurity> <relocation>/media/secure-flash/settings-security.xml</relocation> </settingsSecurity> 
```
  , settings.xml .
  
  , . -, - maven-scm-plugin
  Mercurial.
  , as-is, , , , .
  , .
  SSH- Mercurial. , pom.xml :
```
 <scm> <url>https://bitbucket.org/googolplex/devourer</url> <connection>scm:hg:https://bitbucket.org/googolplex/devourer</connection> <developerConnection>scm:hg:ssh://hg@bitbucket.org/googolplex/devourer</developerConnection> </scm> 
```
  . SSH- , . , VCS . — . , . settings.xml , :
```
 <profiles> <profile> <id>gpg-passphrase</id> <activation> <activeByDefault>true</activeByDefault> </activation> <properties> <gpg.passphrase>passphrase</gpg.passphrase> </properties> </profile> </profiles> 
```
  , maven-gpg-plugin
  , ,
  ( ).
  
  — ( GnuPG)
  " " GnuPG .
  settings.xml pom.xml .
  
  settings.xml :
```
 <profiles> <profile> <id>gpg-passphrase</id> <activation> <activeByDefault>true</activeByDefault> </activation> <properties> <gpg.passphrase/> <gpg.home>/media/secure-flash/gnupg</gpg.home> </properties> </profile> </profiles> 
```
  maven-gpg-plugin pom.xml :
```
 <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-gpg-plugin</artifactId> <version>1.4</version> <configuration> <passphrase>${gpg.passphrase}</passphrase> <homedir>${gpg.home}</homedir> </configuration> <executions> <execution> <id>sign-artifacts</id> <phase>verify</phase> <goals> <goal>sign</goal> </goals> </execution> </executions> </plugin> 
```
  , gpg.home , GnuPG
  , .
  
  — , . For
  maven-gpg-plugin pom.xml . , , : mvn release:prepare mvn release:perform . Unix-, , , , SSH- : 600, - . — settings.xml . . — : mvn release:prepare -Dgpg.passphrase=passphrase , , , , . mvn --encrypt{,-master}-password : , . , , ~/.zsh_history . , , , ~/.viminfo ~- . , . , - .
  Conclusion
  
  , Maven Central — Java ,
  , Java. ,
  , . ,
  . Thanks for reading.
  
  , .
  
  Emacs Org Mode, Org -> Docbook -> Habr Exporter .

Source: https://habr.com/ru/post/171493/

All Articles

Publishing an artifact to Maven Central via Sonatype OSS Repository Hosting Service

Create a ticket on Sonatype JIRA

We create and prepare artifacts for unloading.

Configuring GnuPG to sign artifacts

Configuring mavena to automatically sign and download artifacts in snapshot and staging repositories

Uploading artifacts to the repository

settings.xml

Conclusion

More articles: