Discussion :

[ehsavoie]

Bonjour,
J'ai réalisé un petit mojo dans mon coin que j'ai proposé pour intégration au maven-changes-plugin. En gros j'analyse les logs subversion pour produire une changelog. Ca évite d'avoir un fichier changes.xml à éditer à la main. C'est indépendant du bug tracker même si pour l'instant j'en ai mis 2 à titre d'exemple.
De même pour les patterns dans les logs, on peut facilement en ajouter d'autres si ceux que j'ai instrumentés ne vous plaisent pas.
Pour plus d'informations : http://jira.codehaus.org/browse/MCHANGES-78.
J'aurais aimé savoir si un tel mojo vous intéresse, car il n'a pas l'air de soulever l'enthousiasme de l'équipe du maven-changes-plugin
Merci de vos retours.
Emmanuel

[rseM2]

Bonjour,

De mon côté je pense que c'est très utile et c'est dommage que la communauté maven 2 ne réagisse pas plus surtout qu'à priori tu as fait l'effort de prendre en compte les retours de la communauté (jdk 1.4 et api scm).

Ce serait intéressant d'avoir l'avis d'Emmanuel Venisse...

Merci en tout cas pour le travail réalisé et j'espère bien que cette évolution sera prise en compte pour pouvoir l'utiliser. J'ai voter pour !

Rémy

[Tueur_a_gage]

J'ai trouvé la solution utile pour mon projet.... je pense l'utiliser si la communauté veut bien la prendre en compte.

Un grand merci à ehsavoie

merci

[evenisse]

Il semble que tu as créé un nouveau plugin au lieu de mettre à jour le plugin changes. Dans ce cas, il n'est pas à sa place dans cette entrée Jira.
Si tu veux l'intégrer sur mojo.codehaus.org, envoie un mail à la liste du projet Mojo pour le proposer comme nouveau plugin.

[ehsavoie]

Je ne suis pas tout à fait d'accord, je produis un rapport équivalent à celui de changes simplement j'utilise les logs svn plutôt qu'un document XML.
Là où je suis un peu déçu c'est que cette remarque (que j'accepte tout à fait) aurait dû être faite dès le début plutôt que de me demander des modifications successives. J'aurais alors mis le plugin chez Codehaus, ce que je vais m'empresser de faire maintenant .
Emmanuel

[rseM2]

Honnêtement j'avoue que je rejoins l'avis d'emmanuel (ehsavoie) et que la communauté maven n'est pas très clean sur ce point.

En effet, on peut refuser une amélioration pour deux raisons : soit pour le fond, soit pour la forme.

Il semble d'après les échanges sur l'issue que les rejets étaient plutôt sur la forme que sous le fond (jdk1.4, api-scm...) alors qu'on a l'impression que la communauté maven ne souhaite pas inclure cette amélioration dans le plugin maven-changes-plugin pour je ne sais quelle raison. Dans ce cas, cela aurait été mieux de l'indiquer tout de suite. En tout cas, il n'y a pas eu de nouveaux commentaires sur l'issue pour indiquer si elle sera ou non prise en compte et pourquoi.

De plus c'est un peu bizarre de dire que c'est un nouveau plugin alors qu'il produit exactement le même rapport sauf qu'il se base sur les commentaires svn plutôt que sur un fichier texte. Je considère que c'est une amélioration du plugin car cela facilite la gestion et l'évolution des informations des changements du projet. En effet, c'est plus facile de gérer cela au fil de l'eau lors du commit plutôt que de mettre à jour le fichier texte où il y a de fortes chance qu'il y ait des oublis.

C'est en tout cas mon avis et si emmanuel (ehsavoie) le mets sous codehaus, on ne peut qu'espérer que le fait que les gens l'apprécient fera en sorte que la communauté maven 2 se penche un peu plus dessus. Néanmoins cela n'apportera que des confusions aux utilisateurs maven 2 qui se demanderont pourquoi ils existent deux plugins qui font la même chose et lequel choisir.

Si d'autres personnes ont un avis, ce serait intéressant qu'il le partage.

Rémy