Services/Nexus

Ed Willink's commentary: Further to a request on Bug 562307, I provide a commentary on the deficiencies of this Wiki page; a commentary, since as a complete idiot newbie when it comes to Maven, my comments may not be correct. However bottom line, unless you emulate the heroism of the platform in Publish_To_Maven_Central you may not achieve a great deal by reading on.

Eclipse Nexus Instance

The Eclipse Nexus instance is hosted at: https://repo.eclipse.org

This repository allows Eclipse projects to publish their build artifacts into a centralized repository hosted by EMO.

Notes:

• Snapshots older than 30-days are automatically removed on a weekly basis

Getting a Nexus repo for your Project

Simply file a Bug and specify what project you'd like a Nexus repo for.

Ed Willink's commentary: You will not be given permission to login to repo.eclipse.org and even if your could, it is not clear what you can do. If you mess up and need something deleted, you will need to file a Bugzilla.

Pulling artifacts from Nexus

To use repo.eclipse.org to pull artifacts for your project there are a few URLs that can be used.

Releases Group

https://repo.eclipse.org/content/repositories/releases/

This URL is a top-level aggregate of all project releases repositories. This URL is recommended if you just want to pull in releases from any project hosting artifacts on repo.eclipse.org

Snapshots Group

https://repo.eclipse.org/content/repositories/snapshots/

This URL is a top-level aggregate of all project snapshots repositories. This URL is useful for developers who want to pull in artifacts that may have not yet been released usually nightlies.

Project Specific Repos

Finally you can also use a project specific repo if you only want to ensure you are only pulling artifacts from specific projects. To get the URLs for these projects you can navigate to https://repo.eclipse.org/index.html#view-repositories and browse for the URL link for the specific project.

Deploying artifacts to repo.eclipse.org

To deploy artifacts to repo.eclipse.org you will need to use Jenkins (http://ci.eclipse.org) to configure a job for deploying your artifacts.

It is recommended that you use JDK 7 or higher as we have seen SSL Handshake issues when using JDK 6.

Initial Maven POM setup

Before Jenkins can deploy your project's artifacts to Nexus you will need to do some setup on the Maven side to add a "distributionManagement" section to your project pom. An example below:

  <distributionManagement>
    <repository>
      <id>repo.eclipse.org</id>
      <name>Project Repository - Releases</name>
      <url>https://repo.eclipse.org/content/repositories/project-releases/</url>
    </repository>
    <snapshotRepository>
      <id>repo.eclipse.org</id>
      <name>Project Repository - Snapshots</name>
      <url>https://repo.eclipse.org/content/repositories/project-snapshots/</url>
    </snapshotRepository>
  </distributionManagement>

Replace instances of the word "project" with your project's name.

Note: It is important to ensure your ID's are "repo.eclipse.org" as the Jenkins instance is configured to use these IDs.

Ed Willink's commentary: It is not clear where the above lines should be put. At the same level as build and above profiles in the root pom.xml seems to 'work' for me, but since everything inherits the root pom.xml, this means that test functionality is also published. It also means that as each plugin is signed, it is published as a snapshot, potentially giving a substantial time window in which a consumer can pull a mix and match of old/new snapshots. I have seen no evidence that the recommendations of this wiki enable anything to appear in the releases.

NB a snapshot is a an artifact-id with SNAPSHOT in its spelling. A release is one with a resolved version. Any correspondence with R/S/I/N-builds is coincidental/for you to establish. It might therefore be appropriate to move the 'Project Repository - Releases' to a profile that only runs for R-builds and the 'Project Repository - Snapshots' to profiles for S/I-builds.

However it is far from clear to me why I would want to use Tycho to publish to repo.eclipse.org at all, since it can only publish the workspace slowly and prematurely when perhaps I want to publish the 2019-06 P2 repo that was contributed to the 2019-06 SimRel. For this I need a script that eats the P2 repo, I do not want to have to create a GIT branch with a changed pom.xml in order to attempt a re-build emulating the old release.

If you want to keep several snapshot versions use:

    <snapshotRepository>
      <uniqueVersion>true</uniqueVersion>
      ...

Note: this tag is ignored by Maven 3.x.

Jenkins Job Setup

Using Jenkins you will need to configure Maven to run the "deploy" goal.

There are 2 ways you might want to do this:

1. Simply add the "deploy" goal as one of your Maven goals as part of your build
2. Create separate jobs, one for building and one for deploying (if you want more control over when to deploy)

Ed Willink's commentary: Simply adding "deploy" when you already have another goal such as "verify" in the same lifecycle is not a good idea; the "verify" executes twice, signing at least all sources plugins twice and eventually failing with "Could not assemble p2 repository: Mirroring failed". Replace "verify" by "deploy"

If you decided to go with creating separate jobs, your deploy job will need access to your build job's workspace, an easy way of making this work is to configure the build job, and the deploy job with the optional Use custom workspace configuration under Advanced project options.

Ed Willink's commentary: The following instructions pre-date the auto-deletion of workspaces by the new JIRO infrastructure.

Example:

Replace <your build job project name> with the name of your project job, for example if your build job was named cbi-maven-plugins-build and your project cbi, then your Directory should be /jobs/genie.cbi/cbi-maven-plugins-build/workspace/. This setting should be configured in both your Build job and Deploy jobs.

Shared workspaces
This only applies to JIPP instances on our old infrastructure. Shared workspaces are not supported on our new cluster-based infrastructure.

Finally your deploy job should invoke an instance of Maven 3 with the "deploy" goal. The only additional option you need to ensure that's configured is to click Advanced and configure the Settings option and set it to Deploy to repo.eclipse.org. This custom settings file contains the necessary credentials in order for you to deploy to repo.eclipse.org.

Update 29.03.2017: This is not longer necessary when you want to deploy to repo.eclipse.org or repo.locationtech.org. The credentials have been merged into the general Maven settings.xml file that all JIPPs are using.

Please note: a special settings.xml file is still necessary when deploying to OSSRH.

Deploying a jar to repo.eclipse.org

It is possible to use the Maven deploy:deploy-file goal to push a jar file into https://repo.eclipse.org via Jenkins. For every jar you wish to push into https://repo.eclipse.orgrepo.eclipse.org an associating pom.xml file is necessary.

The simplest pom.xml can be as follows:

<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.eclipse.jdt</groupId>
  <artifactId>org.eclipse.jdt.core</artifactId>
  <version>3.9.0.v20130313-2254</version>
</project>

Every JIPP has access to the same /shared as build.eclipse.org so placing your files somewhere there will allow Jenkins to be able to find it.

Configuring Jenkins for mvn deploy:deploy-file

There are 3 settings which need to be configured:

1. Goals: deploy:deploy-file
2. Properties:

   groupId=<groupId>
   artifactId=<artifactId>
   version=<version>
   packaging=jar
   file=/shared/path/to/file.jar
   repositoryId=repo.eclipse.org
   url=<Your project's repo URL to push jar into>

3. POM File: /path/to/pom.xml

For example:

Note: You will also need to configure your settings file to use Deploy to repo.eclipse.org per instructions in the previous section for deploying artifacts.

Deploying to repo.eclipse.org with Gradle

If you are using Gradle in your build job, you can also deploy to repo.eclipse.org from your JIPP instance as described in the Gradle user guide.

Include in your gradle script authentication configuration using the settings below, e.g.

repositories {
  maven {
    credentials {
      username eclipseRepoUsername
      password eclipseRepoPassword
    }
    authentication {
      basic(BasicAuthentication)
    }
  }
}

Webmaster will need to setup the Gradle plugin in your JIPP and provide ~/.gradle/gradle.properties with the following two variables:

eclipseRepoUsername=xxx
eclipseRepoPassword=yyy

Please file a bug against Eclipse Foundation > Community > CI-Jenkins for that.