Skip to content

Publish to Maven Central

Jump to bottom
Simeon Andreev edited this page May 24, 2023 · 1 revision

Preparing a Repository

Unless stated otherwise the following steps are implemented using bash scripts.

Preparing the tools

  • unpack Eclipse SDK for use as director application (can we use a smaller installation?)
  • install the cbiAggregator

Run the aggregator

  • the aggregation model basically pulls everything from a given release repo
  • configure for all operating systems
  • specifies these properties: packedStrategy="UNPACK_AS_SIBLING" mavenResult="true" versionFormat="MavenRelease"
  • define maven mappings to map all 3rd party artifacts to their original GAV, as of SDK Neon.2 these are:
    • com/jcraft/jsch/0.1.53
    • com/ibm/icu/icu4j/56.1.0
    • commons-jxpath/commons-jxpath/1.3.0
    • javax/inject/javax.inject/1.0.0
    • junit/junit/4.12.0
    • org/apache/xmlgraphics/batik-css/1.7.0
    • org/apache/lucene/lucene-analyzers/3.5.0
    • org/apache/lucene/lucene-core/3.5.0
    • org/apache/felix/org.apache.felix.gogo.runtime/0.10.0
    • org/apache/felix/org.apache.felix.gogo.shell/0.10.0
    • org/apache/ant/ant/1.9.6
    • org/tukaani/xz/1.3.0
    • org/ow2/sat4j/org.ow2.sat4j.core/2.3.5
    • org/ow2/sat4j/org.ow2.sat4j.pb/2.3.5
    • org/ow2/asm/asm-tree/5.0.1
    • org/ow2/asm/asm/5.0.1
  • Since Neon.3 some of the above specify Version Pattern/Template in order to cut of undesired ".0" parts, so junit, e.g., is now 4.12, not 4.12.0

Remove undesired content

  • p2-only content: p2.index p2.packed content.jar artifacts.jar
  • all features (irrelevant in plain maven use): *feature.group and *feature.jar
  • test plug-ins: org/eclipse/*/*test*
  • tooling* (what is this?)
  • directories containing a pom but no corresponding jar file
  • "garbage", i.e., 3rd party artifacts that after previous clean-up are no longer referenced from any org/eclipse/{platform,jdt,pde} pom files
  • directories that are empty after previous clean-up

Technically, some of the clean-up is not necessary, but it helps to give a good picture of what will be published.

Enrich POMs

This step is implemented as a small Java tool.

Add some required information to the generated poms:

  • dynamic content (retrieved mostly from MANIFEST.MF):
    • name (typically matches what the aggregator filled in as description)
    • url
    • scm connection, tag and url
  • semi dynamic content
    • developers (start from the git url, and match it against known project names to link to the corresponding "Who's Involved" page of PMI)
  • static content
    • copyright
    • license
    • organization
    • issue management
  • hard wired corrections
    • scm connection for emf & ecf
    • fix name of org.eclipse.core.resources.win32.x86* fragments
  • fix checksums (md5 & sha1 after pom update -- not needed for publishing)

Add Javadoc stubs

Use a heuristic mapping from bundle name to name of the doc bundle holding corresponding javadoc, one of:

  • org.eclipse.jdt.doc.isv
  • org.eclipse.pde.doc.user
  • org.eclipse.platform.doc.isv

Then

  • create a README.txt referring to the doc bundle
  • jar the README.txt
  • copy the jar to the locations so that it will be picked up by maven

Create missing sources artifacts

Workaround for sources artifacts missing for 8 artifacts ().

  • org.eclipse.core.net.win32.x86_64
  • org.eclipse.core.net.win32.x86
  • org.eclipse.core.net.linux.x86_64
  • org.eclipse.core.net.linux.x86
  • org.eclipse.tips.ui
  • org.eclipse.tips.json
  • org.eclipse.tips.ide
  • org.eclipse.tips.core

Create sources jars:

  • check out sources from git
  • respect content of build.properties
  • manually jar it up and put it into the location expected by maven

Sign and Upload to OSSRH

Steps:

  • copy relevant section of prepared repo into current hudson workspace
  • for each *.pom, *.jar, *-sources.jar and *-javadoc.jar
    • invoke maven (cli)
      • pass settings configured for GPG signing and OSSRH account (-s).
      • use a generic pom (-f) (configure maven-gpg-plugin and nexus-staging-maven-plugin (is the latter needed here?))
      • call goal gpg:sign-and-deploy-file
      • passing these properties (-D): url, repositoryId, file, pomFile, classifier

Caveat:

If gpg:sign-and-deploy-file doesn't work for some reason, it's tempting to try manual upload of artifacts instead. This, however, doesn't seem to scale, i.e., it's OK for one artifact, but not for a significant number of artifacts. See how I struggled : OSSRH-27091 comment 389077 (look for item (2)).

Validate and Release

  • Login to OSSRH nexus (personal account must have been assigned permissions for the targeted staging area, simply request this in the Jira ticket).
  • Identify and select the staging repository created by the previous step (name is group-without-dots-dash-number, where number starts at 1000, e.g., orgeclipseplatform-1005)
  • Click close, and wait for validation results to appear under "Activity"
  • On success click release, otherwise click drop, fix errors and try again
Clone this wiki locally