Publication Maven

elide publish construit les JAR d’une bibliothèque, écrit un POM pour ses consommateurs et les publie dans un dépôt Maven : le dépôt local par défaut, un dépôt d’équipe avec --to, ou Maven Central via le Central Publisher Portal. Maven, Gradle et d’autres projets Elide en dépendent ensuite comme de n’importe quel autre artefact. Le bloc publishing de elide.pkl la configure ; aucun plugin n’est à ajouter.

Installer en local

Une publication nécessite un groupId, la version du projet et un artefact Jvm.Jar :

amends "elide:project.pkl"
import "elide:Jvm.pkl" as Jvm

name = "greeter"
version = "1.0.0"
description = "Greets people."

artifacts {
  ["lib"] = new Jvm.Jar {}
}

publishing {
  maven {
    groupId = "dev.example"
  }
}

elide publish

Elide construit le JAR (en réutilisant les sorties à jour), écrit le POM et installe les deux en tant que dev.example:greeter:1.0.0 sous ~/.m2/repository, avec maven-metadata-local.xml. L’artifactId vaut par défaut le nom du projet. Réinstaller la même version la remplace : un consommateur sur la même machine récupère donc chaque modification. Depuis Maven :

<dependency>
  <groupId>dev.example</groupId>
  <artifactId>greeter</artifactId>
  <version>1.0.0</version>
</dependency>

Depuis Gradle :

repositories { mavenLocal() }
dependencies { implementation("dev.example:greeter:1.0.0") }

Depuis un autre projet Elide :

dependencies {
  maven {
    packages { "dev.example:greeter:1.0.0" }
  }
}

Une installation locale ne demande ni réseau ni identifiants. localRepository installe ailleurs ; un chemin relatif est résolu par rapport au manifeste.

Vérifier avant de publier

elide publish --dry-run

--dry-run prépare le POM et les JAR sous .dev/staging/publish/maven avec les noms de fichiers Maven (greeter-1.0.0.jar, greeter-1.0.0-sources.jar, greeter-1.0.0.pom) et les liste. Il les signe si la signature est activée et, pour Maven Central, écrit aussi le bundle : il montre donc exactement ce qu’une vraie exécution enverrait. Rien n’est écrit dans un dépôt.

Contenu du POM

Le POM décrit la bibliothèque pour ses consommateurs, pas le build : coordonnées, métadonnées pom et dépendances, sans <build>, <repositories> ni chemins locaux.

Par défaut, une publication contient chaque Jar, SourceJar et JavadocJar que déclare le projet ; artifacts en choisit un sous-ensemble par nom d’artefact. Elle doit contenir exactement un Jar, et chaque classifier une seule fois. Un JavadocJar sur des sources Kotlin est généré avec Dokka (voir Assemblage JAR).

Publier dans un dépôt d’équipe

Nommez le dépôt sous repositories, puis publiez-y par son nom :

publishing {
  maven {
    groupId = "dev.example"
    repositories {
      ["internal"] = "https://repo.example.dev/releases"
    }
  }
}

export ELIDE_MAVEN_INTERNAL_USERNAME=ci
export ELIDE_MAVEN_INTERNAL_PASSWORD="$REPO_TOKEN"
elide publish --to internal

Les identifiants viennent de ELIDE_MAVEN_<NAME>_USERNAME et ELIDE_MAVEN_<NAME>_PASSWORD, où <NAME> est le nom du dépôt en majuscules, chaque autre caractère étant remplacé par _ (my-repo → ELIDE_MAVEN_MY_REPO_…) : le manifeste ne contient ainsi aucun secret. Chaque fichier est envoyé avec les sommes de contrôle .md5, .sha1, .sha256 et .sha512, et maven-metadata.xml est mis à jour. Cela fonctionne avec Nexus, Artifactory, GitHub Packages et tout dépôt qui accepte les envois Maven. Une URL http:// simple autre que localhost est refusée sans --allow-http-repositories.

Signer avec gpg

publishing {
  maven {
    signing { gpg { keyName = "0123ABCD" } }   // `signing {}` uses gpg's default key
  }
}

Lorsque signing est défini, une publication distante signe chaque fichier avec le binaire gpg (<file>.asc). Une installation locale ne signe qu’avec --sign ; --no-sign désactive la signature. gpg-agent demande la phrase secrète ; en CI, définissez ELIDE_GPG_PASSPHRASE et Elide la transmet à gpg via pinentry en mode loopback. Elide ne lit jamais la clé lui-même. Si gpg est absent ou échoue, rien n’est publié.

Publier sur Maven Central

Maven Central exige des métadonnées POM, des JAR de sources et de javadoc, des signatures et une version de release. Une bibliothèque complète :

amends "elide:project.pkl"
import "elide:Jvm.pkl" as Jvm
import "elide:Publishing.pkl" as Publishing

name = "greeter"
version = "1.0.0"
description = "Greets people."

artifacts {
  ["lib"] = new Jvm.Jar {}
  ["sources"] = new Jvm.SourceJar {}
  ["javadoc"] = new Jvm.JavadocJar {}
}

publishing {
  maven {
    groupId = "dev.example"
    pom {
      name = "Greeter"
      url = "https://github.com/example/greeter"
      licenses { new { name = "Apache-2.0"; url = "https://www.apache.org/licenses/LICENSE-2.0" } }
      developers { new { id = "jdoe"; name = "J. Doe" } }
      scm { url = "https://github.com/example/greeter" }
    }
    repositories {
      ["central"] = new Publishing.CentralPortal {}
    }
  }
}

Créez un jeton utilisateur dans le Central Publisher Portal et publiez :

export ELIDE_MAVEN_CENTRAL_USERNAME=<token user>
export ELIDE_MAVEN_CENTRAL_PASSWORD=<token password>
elide publish --to central

Avant de construire quoi que ce soit, Elide vérifie les exigences de Central et signale tout ce qui manque en une fois : name, description, url, licenses, developers et scm.url du POM, un SourceJar, un JavadocJar et une version qui n’est pas un -SNAPSHOT. La description du POM vaut par défaut celle du projet. Central signe toujours, avec la clé par défaut de gpg sauf si signing en choisit une ; --no-sign est donc refusé.

Elide envoie un seul bundle signé et accompagné de sommes de contrôle, puis attend que le Portal le valide. Par défaut (publishingType = "USER_MANAGED"), vous publiez ensuite le déploiement dans le Portal ; Elide affiche sa page. Avec publishingType = "AUTOMATIC", le Portal le publie dès qu’il est validé. En cas d’échec de la validation, Elide affiche les erreurs du Portal. --no-wait rend la main juste après l’envoi.

Espaces de travail

Dans un espace de travail, définissez la configuration commune une seule fois dans le elide.pkl racine :

import "elide:Publishing.pkl" as Publishing

publishing {
  maven {
    groupId = "dev.example"
    pom { url = "https://github.com/example/greeter"; scm { url = "https://github.com/example/greeter" } }
    repositories { ["central"] = new Publishing.CentralPortal {} }
  }
}

Les membres héritent de tout sauf artifactId et artifacts, propres à chaque projet ; les réglages d’un membre l’emportent champ par champ, et les dépôts sont fusionnés par nom.

Chaque projet est construit, préparé et signé avant qu’aucun ne soit publié : un échec à ce stade ne publie donc rien. Vers Maven Central, tous les projets partent dans un seul déploiement que le Portal valide et publie d’un bloc. --skip-existing permet aussi de relancer une release interrompue en cours de route : il laisse de côté ce qui est déjà arrivé et n’ignore jamais un snapshot.

En CI

- run: elide publish --to central --skip-existing
  env:
    ELIDE_MAVEN_CENTRAL_USERNAME: ${{ secrets.CENTRAL_USERNAME }}
    ELIDE_MAVEN_CENTRAL_PASSWORD: ${{ secrets.CENTRAL_PASSWORD }}
    ELIDE_GPG_PASSPHRASE: ${{ secrets.GPG_PASSPHRASE }}

Importez la clé de signature dans le trousseau gpg du runner lors d’une étape précédente. Voir Intégration continue pour installer Elide sur le runner.

Référence

• elide publish : toutes les options.
• publishing : toutes les propriétés du manifeste.
• Export POM : afficher un pom.xml pour le build au lieu de publier.