libération Maven via Hudson

Question

Je suis la mise en place d'Hudson à utiliser le plug-in-tâche en mode batch pour faire Maven communiqués à notre référentiel interne. Je le fais via:

mvn --batch-mode release:prepare
mvn --batch-mode release:perform

Je suis intéressé par les autres méthodes ont utilisé et les avantages et les inconvénients de ces méthodes. De plus, les gens ont Gotchas rencontré.

Answer 1

J'ai eu tendance à faire les versions toujours à la main pour quelques raisons. Tout d'abord si vous devez restaurer il est plus facile quand vous pouvez revenir à l'emplacement de sortie d'origine et de le faire. Ensuite, parce que vous devez résoudre toutes les dépendances de l'instantané dans le cadre du processus.

Notre processus de développement nous a laisser les dépendances externes à la version actuelle à la version précédente jusqu'à ce qu'un correctif nécessite une mise à niveau. Cela signifie que si je publie Nexus, Maven, etc, je vois des instantanés et cela signifie que je dois partir et libérer les premiers. Ce processus n'est pas vraiment possible d'automatiser car elle varie en fonction de ce qui a changé depuis la dernière version.

Cela dit, nous avons une machine spéciale (à Sonatype il est juste un vm) configuration uniquement pour construit. Ceci est fait pour garantir l'absence de changements environnementaux se produisent qui pourraient influer sur une accumulation accidentelle (comme un changement jdk). Il rend également plus facile pour quiconque de prendre le processus de libération, car il est toujours prêt à aller.

Answer 2

Récemment, un plugin m2release est venu à mon attention. Semblait agréable. Althought, je l'aurais aimé mon processus de libération pour être complètement «libre-pom-peaufinage». Ce que je veux dire par là que nous devons fournir 4 paramètre d'entrée pour traiter une version complète:

1. la version (ex. 1.0.0)
2. la nouvelle version de développement (ex. 1.0.1-snapshot)
3. la balise de libération dans SCM (ex. Release-1.0.0 ou version 1.0.0)
4. le chemin de base tag SCM

Le premier 2 ont les valeurs par défaut acceptables. La version cognant à la version bug-fix chiffre est parfaitement bien pour moi.

Numéro 4 peut être spécifié dans la pom. Il ne changera pas.

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-release-plugin</artifactId>
    <configuration>
        <tagBase>https://example.com/svn/myProject/releases</tagBase>
    </configuration>
</plugin>

Il est le troisième qui me empêcher d'une automatisation complète d'une version à la simple pression d'un bouton. L'étiquette de la version par défaut ne le faire pour nous, donc nous devons préciser:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-release-plugin</artifactId>
    <configuration>
        <tag>release-${pom.version}</tag>
        <tagBase>https://example.com/svn/myProject/releases</tagBase>
    </configuration>
</plugin>

Maintenant, alors que cela pourrait être juste ce que je avais besoin, je finis par avoir une étiquette svn avec le -snapshot à la fin. :( Donc, je dois passer le paramètre de balise dans la configuration d'emploi Hudson. De plus, je dois changer pour chaque version que nous faisons ... ce qui est pas exactement ce que je dois.

---

Alors, à la fin, ayant un projet de type maven2 dans hudson + le plugin hudson m2release + la version plugin Maven correctement configuré est la mère de tout le processus de libération, je l'ai vu jusqu'à présent. Bien qu'imparfaite, il m'a sauvé beaucoup de travail tiedous.

JS.

Answer 3

J'ai toujours déclenché manuellement une version avec des avantages et des inconvénients évidents: -)

Answer 4

Nous avons fait des expériences avec le plug-in de sortie Maven Hudson, bien que je suis un peu remis en question avec l'obtenir crédite convenablement les communiqués, sans mauvaises choses comme les mots de passe dans nos fichiers hardcoding de construction.