12
votes

Vérification des fichiers JAR (bibliothèques) dans l'outil de contrôle de version - est-ce une bonne pratique?

Je développe une application Web en Java et j'utilise plusieurs fichiers de jar tiers dans mon dossier lib . J'ai aussi Subversion comme outil de contrôle de la version.

Ma question est, tout en vérifiant dans mes fichiers de projet, dois-je enregistrer les fichiers JAR également ou s'il n'est pas nécessaire pour la version des fichiers JAR car je ne les modifie pas de toute façon?


0 commentaires

4 Réponses :


10
votes

C'est une question assez subjective ... J'applique généralement la règle de base suivante: Si j'ai le code pour construire un binaire, enregistrez le code et jamais le binaire; Si un binaire est nécessaire pour exécuter mon code et provient d'une source externe, vérifiez le binaire.

Notez que vous voudrez vouloir vous conformer à toutes les conditions juridiques pourraient venir en vérifiant dans une tierce partie binaire à votre référentiel.


1 commentaires

Je ne pense pas qu'il y ait des problèmes juridiques, car j'utilise principalement les bibliothèques open source. Oui! J'ai décidé d'enregistrer tous les pots.



8
votes

Je recommanderais que dans la mesure du possible, vous devriez utiliser Maven . Ensuite, vous n'avez pas besoin de vérifier les bocaux tiers dans votre référentiel pour les partager parmi votre équipe de développement (la plupart du temps).

Si vous n'êtes pas déjà au courant, Maven effectue deux tâches majeures: construire une automatisation et une gestion de la dépendance. Chaque projet dispose d'un fichier de descripteur qui configure, entre autres choses, que les pots que vous utilisez comme dépendances. La bonne chose à ce sujet est que Maven résoudra automatiquement pour vous les dépendances de ces bocaux et leurs dépendances, etc.


2 commentaires

Si vous êtes plus à l'aise avec la fourmi, puis Ivy Apache ( ant.apache.org/ivy ) pourrait Soyez plus facile à saisir.


C'est vrai, bien que d'avoir utilisé à la fois la fourmi / lierre et Maven, je préfère loin maven.



1
votes

Je gère les référentiels SVN pour une équipe de développement de taille moyenne et pour faciliter l'utilisation des fichiers binaires d'enregistrement que nous avons besoin; même la nôtre dans certains cas.

Je pense que cela reste pertinent, mais SVN a mal interprété mal avec des binaires. Un développeur Java chez IBM a rencontré cette question, a étudié et a écrit ses conclusions. Vous pourriez trouver cela utile:

Subversion de réglage de la performance: stocker et gérer des fichiers binaires sans la performance glisser

Voici l'emporter:

Les conclusions de cette enquête sont clairement spécifiques au système être étudié, il est donc peu probable que les valeurs réelles indiquées soient beaucoup d'importance pour d'autres systèmes. Les motifs sont plus importants parce qu'ils seront répliqués dans n'importe quel système de subversion. Selon Nos conclusions, lors de la conservation d'un ensemble de binaires à Subversion:

  • La méthode la plus efficace est de créer un seul fichier compressé contenant le binaire.
  • La méthode la plus efficace spatiale consiste à utiliser le script d'enregistrement efficace de Subversion sur une structure de répertoire régulière.
  • L'utilisation de toute forme d'authentification sur le serveur Subversion entraînera une perte de performance.
  • Une machine dédiée et puissante est optimale pour la subversion en cours d'exécution.

1 commentaires

@koppor: WaybackMachine à la rescousse: Glad 18 personnes avaient la prévoyance de sauvegarder cette page. :)



2
votes

Personnellement, j'essaierais d'éviter de vérifier les dépendances d'un projet dans le référentiel de contrôle de la version SCM. Typiquement, ce serait en utilisant Maven comme suggéré dans une autre réponse et en déployant un référentiel Maven interne de la société qui présente l'avantage de rendre cette ressource locale à l'équipe de développement et de fournir un emplacement dans lequel les artefacts terminés / versionnés de votre projet peuvent résider. .

Le problème que je vois avec des pots étant le SCM est celui qui est avant tout, le SCM consiste à gérer le code source et ils sont optimisés à cet effet. Les artefacts compilés ne sont pas un code source et des fichiers binaires, lorsque vous agissez généralement ou mettez à jour le binaire, vous effectuez une copie du binaire, car la plupart des SCMS ne peuvent pas «diff» un fichier binaire.

Une autre considération est que faites-vous si vous avez deux projets qui ont besoin de dépendances enregistrées? Vérifiez-vous les DEPS séparément dans chaque projet et portez-vous la duplication? Ou faites-vous un troisième projet contenant uniquement les dépendances? Et maintenant, vous gérez manuellement les fichiers JAR dans ce projet. Et si vos deux projets nécessitent des dépendances mutuellement incompatibles?

Troisième, comment gérez-vous les dépendances inter-projets (où l'un de vos projets dépend de l'autre)? Le fichier JAR est-il enregistré dans l'autre? Qu'en est-il du contrôle de la version et d'autres changements? Il vous suffit-il de faire vérifier les deux projets et les obliger à être construits dans un ordre strict?

Dans mon expérience et mon opinion, ces problèmes sont généralement suffisamment suffisants dans le développement de la seule complexité modérée pour répondre à la question définitivement: Non, il n'est pas acceptable de vérifier les dépendances du fichier JAR. Utilisez un système de construction tel que Maven ou Ant + Ivy (ou une autre alternative) qui fournit un moyen d'externaliser la gestion et le stockage des dépendances à partir du système de contrôle de code source.


0 commentaires