Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
RAP/Maven Central
Contents
Contributing RAP Bundles to Maven Central Repository
The Sonatype OSSRH (OSS Repository Hosting Service) provides a Maven repository hosting service for open source projects and can be used to distribute artifacts to the Maven Central Repository. This guide explains the steps to do so.
Note that a configuration for org.eclipse.rap has already been created, see OSSRH-3818, so there is no need to open a JIRA ticket anymore, unless to request publish rights for additional committers. Currently, Ralf Sternberg and Markus Knauer have publish rights.
Final releases and milestones of RAP are usually uploaded and published on Maven Central.
Preconditions
Sonatype account
The person who uploads bundles has to have a Sonatype user account. The userid and password has to be in the Maven settings.xml file as described in the guide mentioned above. See also the Maven settings reference.
Signing key
Jars have to be signed using PGP, this is different from the jarsigner signatures by Eclipse. Thus, the person who signs and uploads the bundles has to create a PGP key and upload it to a key server. This process is explained in this tutorial.
Uploading
Collecting bundles
Create a directory and copy the release (or milestone) versions of the bundles, including source bundles. For RAP 2.0, we've upload these bundles:
- org.eclipse.rap.rwt
- org.eclipse.rap.rwt.osgi
- org.eclipse.rap.jface
- org.eclipse.rap.jface.databinding
In future versions, we might also consider the testfixture.
POM files
For every bundle (except the source bundles), create a pom file with the same name as the jar file, replacing the extension .jar against .pom. The pom files from the last published version may serve as a template.
Version Numbers
Instead of reproducing our build qualifiers, we agreed to use only the human-readable version number in maven. For example, 1.5.0 for a release, or 2.0.0-M1 for a milestone, etc. These numbers go into the version element in the pom files.
Dependencies
The dependencies have no meaning at deployment time, so I'm not sure if these elements are needed at all.
Upload to a staging repository
When everything looks good, this shell script can be used to sign and upload the artifacts to a staging repository:
Place the script in the directory that contains the prepared pom files, jar files and source jar files. The script will scan for *.pom files and upload the related jar and source jar files. You can use the parameter -n (--dry-run) to check that all files are found by the script.
When all files are uploaded, the staging repository have to be closed in the web interface. The staging repository can then be checked.
Checking
- Compare the .jar files' MD5 checksums with those in the release. Should be the same files.
- Download the jar.asc files, check for valid signature using gpg:
$ gpg *.asc gpg: Signature made Tue 12 Feb 2013 06:15:02 PM CET using RSA key ID 6F18A43A gpg: Good signature from "Ralf Sternberg <rsternberg@eclipsesource.com>"
Publishing
When everything is good to go, press Release. The artifacts will be copied into the Release repository, which is automatically synced to Maven Central every few hours. Note that once published we cannot modify or delete artifacts from Maven Central!
Waiting
http://search.maven.org/#search%7Cga%7C1%7Cg:%22org.eclipse.rap%22