Anonymiser pom.xml à la sortie

Question

J'ai des artefacts qui sont construits et libérés à l'aide de maven. Le pom.xml d'origine de l'Artefact contient les informations habituelles du projet (artefactive, nom, etc.) et les dépendances. C'est très bien. Mais le pom.xml comprend également des informations privées telles que les URL SCM, les noms des développeurs ou un artiste parent.

Existe-t-il un moyen de dire à Maven de générer un pom.xml qui est désinfecté, de sorte que l'artefact peut être libéré en public, sans détruire les informations techniques pertinentes telles que les dépendances?

Ni les URL SCM, ni la liste des développeurs ni l'existence d'un parent-POM (qui n'est utilisé que pour les définitions depmgmt et autres méta-tasts) est à mon humble avis pour les utilisateurs de l'artefact, donc je suppose que je pourrais être supprimé d'un publié pom.xml

Le pom.xml dans un gestionnaire de référentiel tel qu'Archiva et emballé dans le fichier jar d'Atefact contiennent ces informations. Je suppose que Maven copie le tout.

Résumer:

J'ai:

<project>
   <modelVersion>4.0.0</modelVersion>
   <groupId>org.example</groupId>
   <artifactId>my-artifact</artifactId>
    <scm>
        <connection>scm:svn:http://buildmachine/org.example/my-artifact/trunk</connection>
        <developerConnection>scm:svn:http://buildmachine/org.example/my-artifact/trunk</developerConnection>
        <url>http://buildmachine/org.example/my-artifact/trunk</url>
    </scm>
    <dependencies>
        <dependency>
            ...
        </dependency>
    </dependencies>

Je veux:

<project>
    <modelVersion>4.0.0</modelVersion>
    <groupId>org.example</groupId>
    <artifactId>my-artifact</artifactId>
    <dependencies>
        <dependency>
            ...
        </dependency>
    </dependencies>

Answer 1

Je ne connais pas une solution parfaite pour votre problème, mais certaines choses peuvent être faites. Ce sont des hacks, mais ils pourraient aider.
Tout d'abord, externalisez les informations privées de POM (comme SCM, noms de développeurs, etc.). Pour les métadonnées SCM, ce sera:

<scm>
   <connection>${my.scm.connection}</connection>
   <developerConnection>${my.scm.developerConnection}</developerConnection>   
   <url>${my.scm.url}</url>
</scm>

Deuxièmement, déplacer les propriétés à Fichier de paramètres les placer dans un profil. Dans le fichier de paramètres, vous pouvez également "masquer" le référentiel privé de votre entreprise. Si vous devez partager le fichier Profils / Settings.xml avec d'autres associés, essayez d'utiliser le fichier de paramètres global en cours d'exécution mvn -gs path_to_global_settings ou préparez l'installation de Maven commune avec ces paramètres préparés.
La section des parents du parent doit malheureusement rester intact.

Answer 2

Le plugin de version n'a pas de support intégré à cela, à ma connaissance. Deux possibilités me viennent à l'esprit:

Option 1:

• N'incluez pas le pom dans vos pots - vous pouvez contrôler cela à l'aide du paramètre «Archive» dans le pot objectif. <archive><addMavenDescriptor>false</addMavenDescriptor></archive>
• Écrivez un programme pour supprimer les éléments que vous ne voulez pas dans votre POM publié. Vous devriez le faire entre la version: Préparez-vous et publiez: interpréter, ce qui ne fonctionnerait probablement que si vous avez du support dans votre SCM pour modifier les balises après la création, ou effectuer la modification sous une balise / branche différente, puis la libération: Effectuez à partir de là.

Je pense que l'option 1 est déchirante.

Option 2:

• Essayez de tirer parti du paramètre de préparation des orientaux au plugin de libération. Si vous pouvez écrire la manipulation du pom comme des actions maven, elle force être possible de le faire de cette façon.

Je pense que l'option 2 est plus difficile.

Si rien de tout cela ne fonctionne, vous devrez probablement utiliser quelque chose comme la sortie: étape et faire la désinfection à la main, mais vous voudriez toujours exclure les POMS du contenu du pot.

Answer 3

Vous créeriez votre propre archétype pour cela et le publiez au public. Vos utilisateurs pourraient ensuite récupérer l'archétype et configurer leur propre projet en fonction de votre archétype.

Un archétype est un plugin très simple, qui contient le prototype de projet que l'on souhaite créer.

Pour créer un nouveau projet basé sur un archétype, il faut appeler mvn archetype:generate Objectif, comme les suivants:

  mvn archetype:generate                              \
  -DarchetypeGroupId=<archetype-groupId>              \
  -DarchetypeArtifactId=<archetype-artifactId>        \ 
  -DarchetypeVersion=<archetype-version>              \
  -DgroupId=<my.groupid>                              \
  -DartifactId=<my-artifactId>