[https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide This guide] explains the steps to do so.

[https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide This guide] explains the steps to do so.

−

The person who uploads bundles has to have a Sonatype user account.

+

Note that a configuration for org.eclipse.rap has already been created, see [https://issues.sonatype.org/browse/OSSRH-3818 OSSRH-3818], so there is no need to open a JIRA ticket anymore, unless to request publish rights for additional committers. Currently, Beyhan Veliev, Ralf Sternberg and Markus Knauer have publish rights.

−

A configuration for org.eclipse.rap has already been created, see [https://issues.sonatype.org/browse/OSSRH-3818 OSSRH-3818], so there is no need to open a JIRA ticket anymore, unless to request publish rights for additional committers.

+

== Preconditions ==

−

== Signing ==

+

=== 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 [http://maven.apache.org/settings.html Maven settings reference].

+

+

=== Signing key ===

Jars have to be signed using PGP, this is different from the jarsigner signatures by Eclipse.

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.

+

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 [https://docs.sonatype.org/display/Repository/How+To+Generate+PGP+Signatures+With+Maven this tutorial].

This process is explained in [https://docs.sonatype.org/display/Repository/How+To+Generate+PGP+Signatures+With+Maven this tutorial].

−

The userid and passord has to be in the Maven settings.xml file as described in the guide mentioned above. See also the [http://maven.apache.org/settings.html Maven settings reference].

+

== Uploading ==

−

== Which bundles? ==

+

=== Collecting bundles ===

−

For RAP 1.5, we upload these three 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

* org.eclipse.rap.rwt.osgi

* org.eclipse.rap.rwt.osgi

* org.eclipse.rap.jface

* 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.

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, Beyhan Veliev, Ralf Sternberg and Markus Knauer have publish rights.

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.

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!