Andrew Dinn [
http://community.jboss.org/people/adinn] modified the document:
"Publishing javassist releases to Sonatype public repo/maven central"
To view the document, visit:
http://community.jboss.org/docs/DOC-15641
--------------------------------------------------------------
This page describes the process for deploying a javassist project release from relase
3.13.0.GA onwards to the Sonatype public repository and form there to maven central.
Althoguh it focusses on explaing how to upload javassist releases it should provide enough
information to guide anyone wnating to upload some other project's artifacts to
Sonatype/maven central
h1. Why publish to Sonatype?
Previously javassist has published to the JBoss repo. The reason for moving deployment to
the Sonatype repo is that it automatically synchronizes installed jars with maven central.
Although javassist is a JBoss hosted project it is used by non-JBoss projects. So
deploying to Sonatype/maven central gives two successive advantages:
* Projects which have no dependency on JBoss can depend on javassist without needing to
reference the JBoss repo. As a consequence their dependent projects no longer need to
reference the JBoss repoand so on i.e. this removes the need to introduce the JBoss repo
into any upstream dependency chain.
* As a direct consequence projects which depend on javassist can install their jars to the
maven repo. maven central will only host artifacts whose dependencies are also located in
the central repo i.e. it will not allow other repos to be introduced via the downstream
dependency chain.
h1. pom Conformance Requirements
Sonatype and maven central are fussy about what they expect to find in their poms. The
javassist pom had ot be modified to meet these
https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repositor...
pom conformance requirements.
h1. Locating Old and New javassist Releases
As of release.3.13.0.GA the javassist project is now set up to publish releases to the
https://oss.sonatype.org/index.html#view-repositories;public Sonatype public repo.
Sonatype will ensure that these new releases are automatically synced with the
http://repo2.maven.org/maven2/ maven central repo. From there they will be inherited by
the JBoss public repo and so will automatucally be available for use by JBoss.
In order to conform to Sonatype and Maven Cetral guidelines all releases from 3.13.0.GA
onwards are installed using groupid org.javassist. Older releases currently located in
the JBoss public repo under the old groupid javassist are in the process of being
migrated into the maven central repo under the old groupid. However, they are still
available at the JBoss repo.
Snapshot releases are still only deployed to the JBoss snapshots repo. At some point this
will be changed so that they are deployed to the sonatype public snapshots repo but this
change is not critical.
h1. Deploying a javassist tags Release
Deployment of a release from the svn tags tree requires first checking out the tag
n.b. ensure that the version tags defined in pom.xml and build.xml match those used to
create the svn tags directory
pom.xml
. . .
<groupId>org.javassist</groupId>
<artifactId>javassist</artifactId>
<version>X.Y.Z-GA</version>
. . .
build.xml
. . .
<property name="dist-version" value="javassist-X.Y.Z-GA"/>
Anyone with appropriate upload permission can deploy directly to the JBoss repo.
$ mvn javadoc:jar deploy
This should install a class jar, a source jar and a javadoc jar in the
https://repository.jboss.org/nexus/index.html#stagingRepositories JBoss staging repo. You
can then follow the
http://community.jboss.org/wiki/MavenDeployingaRelease usual process
for closing, validating and then promoting the jars to the public repo.
Uploading to the Sonatype repo requires some preliminary steps described below. Once
these have been performed it is almost as simple as uplaoding to the JBoss repo:
$ mvn -P centralRelease javadoc:jar deploy
This should install a gpg-signed class jar, source jar and javadoc jar in the
https://oss.sonatype.org/index.html#stagingRepositories Sonatype staging repo. You use the
http://community.jboss.org/wiki/MavenDeployingaRelease same process for closing,
validating and then promoting the jars to the public repo as applies with the JBoss
staging repo.
h1. Preliminaries Steps for Sonatype Upload
There are several preliminary steps which must be performed before you can upload to the
Sonatype repo.
h2. Add a Developer Entry
The pom shoud be updated to include your details as a javassist developer in the
developers section. Ideally this should done before a release has been tagged.
<developers>
. . .
<developer>
<id>adinn</id>
<name>Andrew Dinn</name>
<email>adinn(a)redhat.com (mailto:adinn@redhat.com)</email>
<organization>JBoss</organization>
<
organizationUrl>http://www.jboss.org/</organizationUrl>
<roles>
<role>contributing developer</role>
</roles>
<timezone>0</timezone>
</developer>
. . .
h2. Acquire Sonatype JIRA Login
You need to obtain a login for the Sonatype JIRA system. This allows you to raise a JIRA
to negotiate access to the repo. It is also used as your login when uplaoding to the
repo.
* Go to the front page of the
https://issues.sonatype.org/ Sonatype JIRA system and click
where it says sign up for an account under the box asking for a user name
* Raise a JIRA asking to be added to the list of org.javassist developers with upload
capability (here is the
https://issues.sonatype.org/browse/OSSRH-570 original JIRA which
requested permission to uplaod the project)
h2. Obtain and Export a gpg Public Key
The Sonatype repo requires all jars to be signed so you need to obtain a signing key and
export it to a public key server in order for the signed jars to be verified. If you
already have a gpg key then you only need to perform the export step.
* Create a gpg key
$ gpg2 ---gen-key
gpg (GnuPG) 1.4.10; Copyright (C) 2008 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Please select what kind of key you want:
(1) RSA and RSA (default)
(2) DSA and Elgamal
(3) DSA (sign only)
(4) RSA (sign only)
Your selection?
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048)
Requested keysize is 2048 bits
Please specify how long the key should be valid.
0 = key does not expire
<n> = key expires in n days
<n>w = key expires in n weeks
<n>m = key expires in n months
<n>y = key expires in n years
Key is valid for? (0)
Key does not expire at all
Is this correct? (y/N) y
You need a user ID to identify your key; the software constructs the user ID
from the Real Name, Comment and Email Address in this form:
"Heinrich Heine (Der Dichter) <heinrichh(a)duesseldorf.de
(mailto:heinrichh@duesseldorf.de)>"
Real name: Fred Bloggs
Email address: fred.bloggs(a)jboss.org (mailto:fred.bloggs@jboss.org)
Comment: Javassist Developer
You selected this USER-ID:
"Fred Bloggs (Javassist Developer) <fred.bloggs(a)jboss.org
(mailto:fred.bloggs@jboss.org)>"
Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O
You need a Passphrase to protect your secret key.
Passphrase: ***********
Repeat Passphrase: ***********
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
..+++++
...+++++
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
....+++++
...+++++
gpg: key 9E0FB9ED marked as ultimately trusted
public and secret key created and signed.
gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0 valid: 2 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 2u
pub 2048R/9E0FB9ED 2010-07-27
Key fingerprint = C469 AD5F EF38 FC57 5230 02CF 9C0C 9DE4 9E0F B9ED
uid Fred Bloggs (Javassist Developer) <fred.bloggs(a)jboss.org
(mailto:fred.bloggs@jboss.org)>
sub 2048R/690CD282 2010-07-27
Note that you are prompted to insert a passphrase which you will also be required to
enter when you use the key to sign the jars. The private and public keys are stored in
dorectory ${HOME}/.gnupg. You can list your keys using command gpg2 --list-keys.
* Make your public key available on key server
hkp://pgp.mit.edu/
$ gpg2 --keyserv
hkp://pgp.mit.edu/ --send-keys 9E0FB9ED
You
can now use your saved key and the passphrase you supplied when you created them to
uplaod to Sonatype. However, you might also want to insatll the passphrase in your
settings.xmlfile so you don't have to keep typing it in every time a jar is
encrypted.
h2. Configure Your gpg Passphrase in settings.xml
Release jars need to be signed in order to upload them to the Sonatype repo so you will be
aksed 3 times for your passphrase unless you configure the mavenbuild with the necessary
information. The sonatype profile (-P centralRelease) in the project pom adds the gpg
plugin to the build. This plugin is configured so that you can pass it a gpg passphrase by
setting the required property in ${HOME}/.m2/settings.xml. Obviosuly you only need to do
this when uploading to Sonatype so it makes sense to place the property in profile entry
labelled with id centralRelease
<profiles>
. . .
<profile>
<id>centralRelease</id>
<properties>
<gpg.passphrase>foobar</gpg.passphrase>
</properties>
</profile>
. . .
--------------------------------------------------------------
Comment by going to Community
[
http://community.jboss.org/docs/DOC-15641]
Create a new document in Javassist Development at Community
[
http://community.jboss.org/choose-container!input.jspa?contentType=102&am...]