Stockage d'applications tierces dans le référentiel d'artefacts

Question

J'apprends des référentiels d'artefacts tels que jFrog Artifactory et Sonatype Nexus. Ils semblent favoriser l'organisation de la façon dont les artefacts Maven, quelque chose comme:

/$groupId/$artifactId/$version/$artifactId-$version.$extension

Je veux stocker tiers applications dans mon référentiel, en plus de mes sorties de construction. De cette manière, les employés disposent d'un emplacement central pour stocker les compilateurs et les applications critiques pour notre processus de création de logiciels.

Quel $groupId dois-je utiliser pour quelque chose comme Notepad++? Son auteur principal est Don Ho, mais si je l'utilise, je pense que cela rendra Notepad ++ difficile à trouver.

Je préfère conserver les noms d'origine des artefacts, tels qu'ils ont été téléchargés à partir d'un tiers, plutôt que de les renommer en $artifactId-$version.$extension. Quels sont les avantages ou les inconvénients de cette approche?

Answer 1

1. Façon de continuer à utiliser le référentiel binaire! Bon mouvement!
2. Une fois que l'application tierce ne sera pas téléchargée par Maven (et je suppose que Notepad ++ ne le fera pas, le sera-t-il?) Le $groupId n'a pas d'importance. Vous pouvez sélectionner ce que vous voulez, par ex. aller avec l'url inversé - org.notepad-plus-plus
3. La question est - comment les utilisateurs vont les utiliser. S'ils vont utiliser n'importe quel moyen non-maven pour les récupérer (UI, scripts REST, Ant, Gradle) alors vous pouvez choisir n'importe quel chemin et nom que vous aimez et vous obtiendrez le support complet d'Artifactory (uploading, search, etc .) Avec Nexus, qui est beaucoup plus axé sur Maven, vous feriez mieux de vous en tenir à la notation Maven ([$groupId]/[$artifactId]/[$version]/[$artifactId]-[$version].[$ext])