Question

Je souhaite conserver un référentiel Maven 2 pour mon organisation. Quels sont certains des indicateurs et des pièges qui pourraient aider.

Quelles sont les directives à suivre par les utilisateurs lors de la définition de normes pour le téléchargement à partir de ou la publication de leurs propres artefacts dans le référentiel lors de la publication de leur code? Quels types de gouvernance / règles avez-vous mis en place pour ce type de choses? Qu'en inclues-tu dans ton guide / documentation pour le développeur?

MISE À JOUR : nous sommes très satisfaits de Nexus. Nous avons suivi la plupart des directives de Sal et nous n’avons rencontré aucun problème. De plus, nous avons limité l'accès au déploiement et la création / déploiement automatisé d'artefacts de capture instantanée via un serveur Hudson CI. Hudson peut analyser toutes les dépendances de projet en amont / en aval. Ainsi, si un problème de compilation, un échec de test ou une autre violation entraîne la rupture de la construction, aucun déploiement ne sera effectué. Soyez fatigué de déployer des instantanés dans Maven2 / Maven3, car les métadonnées ont changé entre les deux versions. Le " Hudson seulement " La stratégie de déploiement d'instantané atténuera ce problème. Nous n'utilisons pas le plug-in de publication, mais nous en avons déjà écrit sur le plug-in Versions lorsque va déplacer un instantané pour libérer. Nous utilisons également m2eclipse et cela semble très bien fonctionner avec Nexus. En effet, le fichier de paramètres permet de voir Nexus et sait indexer les informations sur les artefacts à des fins de recherche. (Bien que j'ai dû modifier certains de ces paramètres pour qu'il indexe entièrement nos instantanés internes.) Je vous recommanderais également de déployer un fichier JAR source avec vos artefacts en tant que pratique standard si cela vous intéresse. Nous configurons cela dans un super POM.

UPDATE2 : je suis tombé sur Ce livre blanc sur Sonatype détaille les différentes étapes de l’adoption / de la maturité, chacune ayant des objectifs d’utilisation différents pour un gestionnaire de référentiels Maven.

Était-ce utile?

La solution

Je vous conseillerais de configurer un serveur Nexus avec au moins quatre référentiels. Je ne recommanderais pas artificiel. La version gratuite de Nexus convient parfaitement à une équipe de développeurs de moins de 20 personnes dans moins de trois groupes. Si vous avez plus d'utilisateurs que cela, rendez-vous service et payez pour la version Sonatype. L’intégration LDAP est rentable.

  1. Libération interne
  2. Instantané interne
  3. tierce partie interne pour le code utilisé en interne provenant de sources extérieures ou pour les versions approuvées par une tierce partie. Mettez les pilotes JDBC, javax. * Et les éléments des clients et partenaires ici.
  4. Proxies externes proxy commun à toutes les sources habituelles telles que m2, codehaus, etc.

Configurez Nexus pour effectuer les opérations suivantes pour les dépôts internes

  1. Supprimer les anciens instantanés à intervalles réguliers
  2. Supprimer les instantanés à la sortie
  3. Construisez les fichiers d'index. Cela accélère aussi les constructions locales

Utilisez un fichier settings.xml commun qui utilise ces quatre sources uniquement. Si vous souhaitez personnaliser davantage la configuration, essayez de conserver une partie commune des paramètres. fichier et utiliser des profils pour les différences. Ne laissez pas vos clients définir leurs propres paramètres, sinon vous obtiendrez un code qui repose sur un ordinateur mais pas sur un autre.

Fournissez un proxy commun à vos clients. Dans Nexus, vous pouvez ajouter un groupe de serveurs proxy aux sources Maven communes (Apache, JBoss, Codehaus) et exposer un seul proxy aux clients internes. . Cela facilite l’ajout et la suppression de sources à vos clients.

Ne mélangez pas les artefacts internes et tiers dans le même référentiel. Nexus vous permet d’ajouter des jars à un référentiel interne via une interface graphique. Je le recommande comme moyen d’ajouter vos pilotes JDBC et d’autres codes externes à des tiers. L’interface utilisateur est plutôt agréable à utiliser par rapport à la plupart des logiciels d’entreprise .

Définissez un POM parent commun définissant l'instantané interne et les mises en pension via la balise distributionManagement . Je sais que beaucoup de gens vous disent de ne pas faire ça. Et bien que j'admette volontiers qu'il y a toutes sortes de problèmes, cela ne pose aucun problème si les clients ne créent que des versions et des instantanés à déployer dans un seul référentiel interne.

Si vous possédez un référentiel Maven mal géré , créez un 5e dépôt appelé Legacy et placez-le dans son intégralité. Configurez une tâche périodique pour supprimer les anciens fichiers de l’héritage une fois qu’ils ont un an. Cela donne à chacun un an pour sortir et mettre à jour ses poms.

Établissez une convention de nommage simple pour les artefacts internes. Je préfère le GroupID de Department.Function.Project et un ArtifactId pour ce nomComposant . Pour les référentiels internes, com / org / net et le nom de l'entreprise sont susceptibles de ne pas être pertinents. Et faux si l'entreprise change de nom. Il est beaucoup moins probable que le service des ventes, de la comptabilité ou des stocks soit renommé.

Autres conseils

Utilisez certainement Nexus . : P

J'ai utilisé à la fois Nexus et Artifactory. L’interface de Nexus est beaucoup plus robuste, plus configurable et bien sûr écrite par Sonatype . , qui représente à peu près tout ce qui est bien Maven.

Cela étant dit, Artifactory est décent et pratique.

Utilisez Artifactory .

J'utilise moi-même Artifactory et j'adore l'interface utilisateur et la facilité de déploiement / maintenance. Cela dit, je n'ai jamais utilisé Nexus et je ne peux pas vraiment vous aider à comparer correctement les fonctionnalités.

Voici quelques points que j’aime beaucoup chez Artifactory (n'oubliez pas que Nexus a peut-être aussi ces fonctionnalités):

  1. Belle interface Web 2.0.
  2. Possibilité d'importer votre référentiel Maven local pour vous aider à démarrer.
  3. Facilité d'intégration avec les serveurs LDAP existants pour la sécurité (je suis un grand fan d'un seul référentiel pour le stockage des informations d'identification).

Etant donné qu'il n'y a en réalité que deux implémentations principales du référentiel Maven, si vous voulez vraiment vous assurer que vous avez fait le bon choix, je vous recommande d'essayer les deux et de choisir vous-même ce que vous préférez.

C’est peut-être évident, mais, pour des raisons de reproductibilité, les développeurs ne doivent jamais écraser les artefacts, mais plutôt les nouvelles versions.

Ceci s'applique également aux référentiels en amont. Si vous téléchargez Apache-commons version 1.2.3, vous ne devriez vraiment jamais le télécharger à nouveau. Les correctifs proviennent de ces dernières versions et ne sont pas appliqués aux versions existantes.

Autre chose à considérer:

http://archiva.apache.org/

En tant que QUESTION ORIGINALE (problèmes techniques à prendre en compte lors de la construction d'un référentiel M2), je vous recommanderais de créer un utilisateur en lecture seule pour parcourir le référentiel et l'utilisateur administratif par administrateur (cela dit: une lecture) -only user pour tous les utilisateurs qui ne sont pas administrateurs). De plus, je recommanderais de générer des images de sauvegarde périodiquement (une fois par jour, peut-être?). Très important si votre référentiel est grand ou si vous installez de temps en temps vos propres artefacts.

Enfin, lors de l'ajout de nouveaux référentiels distants, vous devez ajouter des filtres d'inclusion / exclusion afin qu'une recherche d'artefact dans le référentiel soit effectuée plus rapidement.

Il y a beaucoup d'autres problèmes à prendre en compte, mais ce sont les principaux problèmes que j'ai rencontrés lors de la gestion d'un référentiel interne Maven.

Pour mémoire, j'utilise à la fois Nexus et Artifactory; Je peux clairement affirmer que si Nexus est très simple et opérationnel (bien que le processus d’installation sous Ubuntu pose parfois des problèmes), sa version gratuite ne peut pas rivaliser avec l’édition communautaire (gratuite) d’Artifactory. En excluant la superbe interface Web 2 d'Artifactory, ses principales fonctionnalités, telles que la gestion de la sécurité, les sauvegardes périodiques et les problèmes d'accessibilité dépassent de loin celles de Nexus.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top