Discussion :

[=FdK=]

Voila, je me suis rendu compte que si on faisait un mvn deploy sur un projet en version 0.0.x qui avait deja été deployé, on ecrase la premiere version pour mettre la nouvelle.

Je trouve cela dangereux.
Y a t il une option pour empecher cela.
j'ai regardé dans le plusgin : maven-deploy-plugin mais je n'ai rien trouvé.

Merci de votre aide.

[eclesia]

si les numero de version sont les memes, je trouve tout a fait normal qu'il ecrase l'ancienne. en quoi est ce dangereux ?

si tu voulaid gardé un historique il fallait le faire en amont avec un outil comme HG, SVN ou CVS.

[=FdK=]

Ca se discute non ?

Normalement, une version est unique. quand tu a "figer" une version et généré le jar, il n'y a pas de raison de l'écraser pour généré un jar avec un contenu différent.

La seul raison d'écraser une rélease publiée sur un repository global/inhouse c'est parce que il y a eu une erreur de manip, le développeur à oublier de modifier la version dans son pom.xml avant de vouloir déployé son projet avec des modifs

Imagine:

Un développeur A met à disposition un JAR en Version 0.0.3 à 8h30
un développeur B qui en a besoin récupère donc la V0.0.3 à 9h00.

Le dev A fait une modif et republie son jar avec la meme version mais des class différente à 13h00.
Un Dev C qui en a besoin a 14h30 récupere ce JAR (tj en version 0.0.3).

On arrive dans un cas ou pour une meme version, il y a deux jar différents.



Je trouve donc normal , qu'une fois que la version est publié/déployé on ne puisse pas l'ecrasé => cela pour assuré Une version = un JAR unique (la seul solution serai alors d'aller sur le serveur et de le supprimé directement)

[eclesia]

si tu applique ce que tu viens de dire, je pense que tu t'y prend mal avec maven.

Je suis d'accord sur le fait qu'une version devrait etre unique. Si vous deployez des jar differents sous le meme numero de version c'est que vous ne vous etes pas organisé correctement (manque de communication?).

Mais 2 deploy du meme jar dans la meme journée ? c'est que tes versions ne sont pas de vrai versions mais plutot des SNAPSHOT .

Un deploy de vrai version c'est rare, une fois par semaine, par mois, voir seulement 2/3 fois par an pour les gros projets.

[=FdK=]

Lol non justement je pense qu'on ai d'accord.

Moi je parle d'un cas particulier qui est du a une erreur justement.

En théorie, on est d'accord qu'on ne doit jamais faire de déploy sur un projet avec la meme version mais du contenu différente (sauf SNAPSHOT mais la je parle bien de release)

Moi je parle d'une erreur de manipulation.
c'est a dire, par mégarde ou par oublie de modification du pom.xml apres une release, on en arrive a faire un deploy sur du contenu différente mais avec une version identique.

la ou je suis étoné c'est que rien ne t'en protege. alors qu'il suffirai que maven, au moment du déploy d'une release vérifie qu'il n'y a pas déjà une release de même version deja deployé. (je sais ps si je suis clair lol)

Apres je suis tout a fait d'accord qu ca ne doit jamais arrivé dans un fonctionnement normal.



EDIt : Je pense que c'est mon exemple qui ta troublé.Pour le compléter:
Ici, l'erreur c'est de ne pas avoir modifier le pom.xml (0.0.3 en 0.0.4-SNAP) après le premier deploy.

[aheritier]

Le plugin release est censé eviter en partie cela puisqu'il gère a la place du developpeur le changement des versions dans le pom lorsqu'il fait la release.
Le pom contenant la version sans -SNAPSHOT n'existe que dans le gestionnaire de versions et dans le répertoire target du build. Pour ecraser la version RELEASE il faut donc le faire exprès en recupérant le tag sur le gestionnaire de versions ou en allant modifier et republier le code se trouvant dans le target du projet ...

[=FdK=]

Je suis d'accord sauf que moi je (enfin mes supérieurs) ne veulent pas utiliser ce plugin.

Enfin donc tout ca pour dire qu'il n'existe pas de moyen pour empecher d'ecraser une release.

Merci d'avoir participé

[aheritier]

C'est effectivement bien dommage et dangereux (lorsque c'est possible techniquement). Les controles n'existent pas malheureusement sur les serveurs ou maven lui-même.
Il reste peut etre le moyen d'implementer le controle si le serveur est en apache+webdav en trouvant une config de secu pour eviter l'ecrasement.

[evenisse]

Le contrôle ne devrait pas être compliqué à implémenter au niveau de maven-artifact.
Ouvre une anomalie dans Jira