Si j'utilise le plugin de dépendance maven-dépendance, que je ne peux pas utiliser une plage de version. En outre, il semble que la version d'un artefact définie ne soit pas mise à jour, mais une version plus récente se trouve dans le référentiel à distance.
pourquoi est-ce?
utilise le plug-in Maven-Dépendance que le reste de Maven pour résoudre les dépendances? Et si tel est le cas, pourquoi?
J'ai créé un projet org.example: org.example. Simple.Project1: JAR et le mettre dans le référentiel à l'aide des versions 1.0.0-Snapshot, 1.0.0, 1.0.1 et 1.1.0-instantané J'ai maintenant configuré le plugin de dépendance de la manière suivante: si la résolution de dépendance serait la même que dans les autres dépendances, la Version devrait résoudre (au moins à mon avis) à à la place, je reçois l'exception suivante:
4 Réponses :
Le plugin de dépendance utilise le même mécanisme de résolution que tout le reste. Il se peut que vos référentiels ne mettent pas la mise à jour des métadonnées car le paramètre est défini sur jamais ou hebdomadaire ou quelque chose. Vous pouvez forcer Maven à rafraîchir tous les métadonnées de référentiel à distance en fonctionnant avec A -u.
Le plugin de dépendance n'écrit pas non plus les dépendances téléchargées par défaut si elles existent déjà dans la cible. Vous pouvez faire une propreté ou configurer l'objectif de forcer l'écrasement. Il y a trois paramètres que vous pouvez définir sur true: OverwriteIfNewer , overwrectionlesles et écrasésNapshots . Voir La documentation pour plus de détails.
Edit: En fonction de votre question mise à jour, le problème est que vous utilisez une gamme de dépendances. Les gammes sont bien aussi longtemps que la version (par exemple, vous avez la version définie dans le projet parent ou dans votre section de dépendances). Si vous modifiez la plage en version exacte ou utilisez l'un des Mots-clés de la dernière ou de version , Maven pourra résoudre le numéro de version (bien que ce soit conscient que ces mots-clés portent leurs propres risques.
Je vous recommanderais de définir une section de dépendance dans votre parent avec les versions que vous utilisez, puis vos projets peuvent hériter de ces versions. J'ai répondu à une autre question à ce sujet récemment, je posterai un lien si je le trouve
J'ai mis à jour ma question avec un exemple. Le projet en question est toujours appelé avec -u comme paramètre. Comme dans l'exemple donné, la configuration a défini
Voici une façon de définir vos dépendances dans un projet parent: Stackoverflow.com/Questtions/921599/...
C'est un problème avec les gammes de dépendance en effet.
voir ma réponse ci-dessus. La réponse est en fait que je n'ai jamais mis en œuvre des gammes pour cet objectif.
Le problème des plages de dépendance est que vous n'avez pas spécifié l'une des versions que vous avez utilisées. Si vous avez spécifié la plage en tant que [1.0.0,1.1.0-Snapshot), cela peut le faire comme vous vous attendez. Vous ne pouvez pas supposer 1.0 et 1.1 va résoudre à 1.0. * Et 1.1. * Qui est ce que vous semblez impliquer.
OK Voici la vraie réponse (j'ai écrit le plugin de dépendance):
Les objectifs de déballage et de copie doivent reproduire une partie du code de résolution de base. Malheureusement, ce code de résolution n'était pas vraiment dans une API-sage de forme utilisable. Pour cette raison, ces objectifs ne gèrent pas les gammes de version et ne résolvent pas les artefacts directement du réacteur (je ne les ai franchement jamais mis en œuvre, car il a cassé trop de cas d'utilisation existants, ouais Core Le code de résolution était si mauvais)
Une bien meilleure approche consiste à utiliser les formes de dépendances XXX de ces objectifs. Ces objectifs demandent à Maven de faire la résolution avant d'être invoqués et il est donc compatible à 100%. Vous pouvez utiliser les filtres comme le filtre Groupid et Artifactid pour obtenir efficacement la liste des artefacts que vous souhaitez et le résultat final sera le même.
La copie et le déballer sont définitivement plus flexibles et étaient destinés à un cas d'utilisation beaucoup plus simple que j'avais à l'époque. Connaissant ce que je sais maintenant, je l'aurais probablement impliqué davantage comme les formes de dépendances XXX pour commencer.
Tout ce qui dit, dans Maven 3, le code de résolution est finalement complètement découplé ... Le plugin de dépendance entraînant la plupart des cas d'utilisation nécessaires pour cela. Je vais commencer à travailler sur une nouvelle version du plugin pour tirer pleinement parti de ce bientôt ... et pendant que cela nécessitera Maven 3, cela fonctionnera enfin à 100% avec tous les objectifs.
Hah! Je le savais! Cela explique cela assez clairement. Je vais jeter un coup d'œil à Maven 3, mais je ne suis pas très plein d'espoir, car mes constructions ne fonctionnent pas avec une version maven à autre que 2.0.10 (tant de promesses de compatibilité).
Quelle est la formulaire XXX-dépendances ??
La solution de contournement suggérée provoquera la récupération du fichier zip comme une dépendance transitive par d'autres projets en utilisant ce POM.
@Brianfox Qu'entendez-vous par «Formes de dépendances XXX de ces objectifs»?
à partir de la version 3.0.0 Le plugin de dépendance maven-dépendance prend en charge cela hors de la boîte. Crédits et merci à Brian_fox
Ça ne marche pas pour moi. J'ai < ArtifactItem> de la version [xyz,)