Je serai rapide. Ma version maven est 3.5.0. J'utilise certaines bibliothèques dans mes applications Web. Les bibliothèques sont installées séparément et déployées dans une instance artificielle.
J'ai le pom suivant (une partie de):
<project>
....
<properties>
<process.domain.common.version>0.0.1-SNAPSHOT</process.domain.common.version>
</properties>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>com.intersoft</groupId>
<artifactId>process.domain.common</artifactId>
<version>${process.domain.common.version}</version>
</dependency>
</dependencies>
</dependencyManagement>
<dependencies>
<dependency>
<groupId>com.intersoft</groupId>
<artifactId>process.domain.common</artifactId>
</dependency>
</dependencies>
</project>
mais dans les bibliothèques, Maven met cette bibliothèque:
process.domain.common-0.0.1-20190319.151024-3.jar
au lieu de ceci:
process.domain.common-0.0.1- SNAPSHOT.jar
Mes dépendances sont résolues à partir d'un artificiel. Pourquoi Maven met-il cette bibliothèque temporaire avec un nom d'horodatage au lieu de SNAPSHOT? Ce problème ne se produit pas dans toutes les bibliothèques résolues.
3 Réponses :
Maven ajoute la date actuelle aux instantanés pour comparer la version de l'instantané de votre référentiel local et la version de l'instantané du référentiel distant et évalue s'il est nécessaire de télécharger le fichier à distance, car le téléchargement de 0.0.1-SNAPSHOT aujourd'hui peut donner un fichier différent de celui le télécharger hier ou demain.
Avez-vous un lien officiel qui prend en charge cela? J'ai travaillé avec Maven et je n'ai jamais remarqué cela. De plus, en suivant votre logique et le fait que l'horodatage ajouté va jusqu'aux secondes, si je fais une compilation toutes les minutes, alors chaque minute une nouvelle version doit être téléchargée, sans importance si elle a changé ou non. Cela ne semble pas juste ...
Compris. Mais la question est de savoir pourquoi maven met dans la guerre cette version non officielle du fichier, au lieu de la version normale.
@Theodore semble que vous exécutiez mvn avec des instantanés verrouillés essayez d'exécuter des versions mvn: déverrouillez-les instantanés pour utiliser l'instantané au lieu de la version chronologique
Si vous créez un instantané localement, il est simplement construit avec le nom 0.0.1-SNAPSHOT . Si vous le déployez sur Artifactory, il obtient un numéro de version d'horodatage interne comme celui que vous avez mentionné.
Lorsque vous le téléchargez à nouveau, Artifactory vous donne le dernier horodatage.
Donc localement, vous avez parfois une version -SNAPSHOT et parfois une version horodatée. La règle exacte du nom de l'artefact de la guerre ne m'est pas claire, mais que vous ayez une version horodatée ou non, ça devrait aller.
Enfin, j'ai trouvé la solution.
La solution est d'ajouter le plugin maven war dans votre pom.xml du projet war:
<properties>
<version.war.plugin>2.5</version.war.plugin>
</properties>
<build>
<finalName>${project.artifactId}</finalName>
<plugins>
<plugin>
<artifactId>maven-war-plugin</artifactId>
<version>${version.war.plugin}</version>
<configuration>
<warName>${project.artifactId}</warName>
</configuration>
</plugin>
</plugins>
</build>
Preuve: p>
WEB-INF / lib sans le plugin war:
WEB-INF / lib avec le plugin war:
La version 2.5 a-t-elle fait la différence? Ou avez-vous simplement ajouté l'extrait de code
vient d'ajouter le plugin
est-il possible que vous ayez la version "0.0.1-20190319.151024-3" codée en dur comme une dépendance transitoire. Ce serait à mon avis la seule raison pour laquelle Maven le téléchargerait au lieu de celui spécifié. Avez-vous complètement nettoyé votre environnement local avant la construction (supprimez toutes les bibliothèques précédemment téléchargées)?