2009-06-13 7 views
7

Lorsque nous lançons des projets, ils sont généralement les mêmes à chaque fois. Y a-t-il des arguments ou des propriétés que je peux ajouter à la release: prepare cela permettra de libérer le pattern en mode batch?Maven release properties

Exemple:

 
What is the release version for "MyProject"? (company.jar.site:myproject) 0.0.1: : 
What is SCM release tag or label for "MyProject"? (company.jar.site:myproject) MyProject-0.0.1: : 
What is the new development version for "MyProject"? (company.jar.site:myproject) 0.0.2-SNAPSHOT: : 

Ce serait bien de faire quelque chose comme ceci:

 
mvn -B release:perform -DreleaseVersion:$nextMinorVersion$ or 
mvn -B release:perform -DreleaseVersion:$nextPatchVersion$ or 
mvn -B release:perform -Dtag:v$nextPatchVersion$ or 
mvn -B release:perform -Dtag:v$nextPatchVersion$-someCustomNaming 

Si quelque chose comme cela n'existe pas déjà, je vais créer une coutume Mojo de le faire.

Alternativement, lors des invites ci-dessus, nous faisons généralement par défaut à la première question, «v» + la version actuelle sur la seconde, et la prochaine mineure sur la dernière. Si nous pouvions les modifier d'une manière ou d'une autre, cela résoudrait le problème immédiat.

Merci d'avance.

Répondre

7
mvn -B release:prepare release:perform 

-B est pour le mode de traitement par lots, il utilisera les valeurs par défaut qu'il offre en mode non-batch. Généralement pour X.Y.Z-SNAPSHOT, il effectue une libération de X.Y.Z et définit le nouvel instantané sur X.Y. (Z + 1) -SNAPSHOT.

Comme pour tout ce qui concerne maven, vous pouvez vous battre avec cette convention de dénomination et avoir beaucoup de maux de tête, ou encore décider et décider de vos versions et labels qui seront le maven et en profiteront gratuitement. Je me suis battu, et j'ai perdu. Juste l'une des nombreuses façons que vous devez donner complètement à Maven si vous allez l'utiliser.

Je suis parfaitement heureux de l'avoir fait, vouloir imposer mes propres schémas n'est généralement pas une bonne idée de toute façon.

+0

Le seul problème avec cela est que je veux généralement modifier le nom de tag offert.Parce que mon parent artefactId est généralement "foo-parent" et je veux que la balise soit foo-1.2.3 au lieu de foo-parent-1.2.3. –

2

réponse partielle, après votre comment:

Pour modifier le nom de la balise, utilisez l'argument -Dtag=xxx-release:prepare. Voir the release:prepare documentation pour plus de détails.

code non testé avertissement

Pour ce faire, d'une manière entièrement automatisée, vous devez ajouter une entrée de configuration à votre pom.xml où vous définissez le nom de tag:

<maven-release-plugin> 
    <configuration> 
     <tag>parent-${releaseVersion}</tag> 
    </configuration> 
</maven-release-plugin> 
1

Le comme je l'ai fait est Performing a Non-interactive Release Using a properties file.

Vous créez un release.properties dans la racine du projet aggrégateur (celui qui a l'emballage: pom) et pour chaque projet, vous ajoutez deux propriétés de la forme suivante:

project.rel.<groupId>\:<artifactId>=<releaseVersion> 
project.dev.<groupId>\:<artifactId>=<nextSnapshotVersion> 

si vous voulez utiliser un littéral particulier pour votre tag vous ajoutez la propriété suivante

scm.tag=<tagLiteral> 

Voici un exemple où les deux choses sont faites (préciser la version de chaque module et définir le littéral à utiliser pour marquer dans le SCM):

scm.tag=my-project-0.2.1 
project.rel.org.monachus.monkeyisland\:my-project=0.2.1 
project.dev.org.monachus.monkeyisland\:my-project=0.2.2-SNAPSHOT 
project.rel.org.monachus.monkeyisland\:module-a=0.1.1 
project.dev.org.monachus.monkeyisland\:module-a=0.1.2-SNAPSHOT 
Questions connexes