Dépendances Java lors du développement et du déploiement

Question

J'ai une question générale sur la manière de gérer vos dépendances de jar de compilation et de déploiement. Je dispose généralement les répertoires de développement comme suit pour une bibliothèque/application simple.

Calculator 
    src 
    test 
    build 
    lib 
    … 

Il y a plusieurs façons de le faire, mais c'est ma disposition typique pour les projets génériques. Ma question tourne autour du répertoire lib. Je place généralement des jars dont mon projet dépend dans le répertoire lib (log4j, etc.) Donc, au moment de la compilation, je peux définir mes différents chemins comme lib \ log4j.jar ou quelque chose comme ça. Maintenant, lorsque nous créons un paquet distribuable, j'ai tendance à refléter cette mise en page.

dist 
    Calculator.jar 
    lib 
     log4j.jar 
     addition.jar 
     subtraction.jar 

Cela me permet soit d'installer un script qui définit mon chemin de classe par rapport à l'endroit où le pot principal, ou je peux configurer le classpath dans le manifeste pour le pot principal (Calculator.jar dans ce cas) Cela peut ou peut-être pas la meilleure façon de le faire, mais cela a fonctionné pour moi et semble être la façon acceptée de traiter les dépendances par d'autres développeurs dont j'ai parlé à ce sujet.

Ma question vient quand je veux créer un nouveau projet qui utilise un autre projet que j'ai présenté de cette façon. Donc, disons que je veux créer un nouveau projet de calculatrice qui utilise le projet Calculatrice à partir de l'exemple ci-dessus. Si je suis la même mise en page, je voudrais obtenir quelque chose comme ce qui suit:

dist 
    ScentificCalculator.jar 
    lib 
     Calculator.jar 
     lib 
     Log4j.jar 
     addition.jar 
     subtraction.jar 

Bien sûr, cela pourrait sortir de la main le plus profond de votre arbre de dépendance est:

SuperWhizBangCalculator.jar 
lib 
    ScientificCalculator.jar 
    lib 
     Calculator.jar 
     lib 
     log4j.jar 
     addition.jar 
     subtraction.jar 

Une autre option serait de aplatir l'arbre:

SuperWhizBangCalculator 
    lib 
     ScientificCalculator.jar 
     Calculator.jar 
     log4J.jar 
     addition.jar 
     subtraction.jar 

Mais quelque chose ne semble pas juste à ce sujet. Vous perdez la structure qui vous indique quelles bibliothèques vont avec le composant dont vous dépendez. Je me demandais donc s'il existait une façon standard de faire cela, étant entendu qu'il n'y a jamais de taille unique.

Merci pour le temps ...

Answer 1

Ne répond pas directement à votre question. Mais vous pourriez jeter un oeil à Maven 2 d'Apache qui peut faire la plupart de la "gestion des dépendances" pour vous.

être informé qu'il ya une courbe d'apprentissage à obtenir Maven 2 up, courir et travailler :)

Autre que la troisième option est logique pour moi.

Answer 2

Je ne pense pas que vous trouverez une norme axée sur la collectivité, mais je pense que d'avoir globalement une lib-in-a-lib est pas une bonne idée. Vous risquez de dupliquer de nombreux fichiers jar qui seraient communs à vos projets. Cela gaspille l'espace disque, et vous donne le risque de mettre à jour le pot qui n'est pas le premier dans votre chemin de classe ...

Je pense que votre troisième option est la meilleure.

Aussi, je donnerais une réflexion sur la façon dont Eclipse gère les liens entre deux projets différents ... vous pouvez mettre un projet sur le chemin de la construction d'un autre projet ...

Answer 3

Je serais absolument aller avec le dernière approche. Imaginons un programme A utilisant les bibliothèques B et C qui utilisent toutes les deux D. Dans une mise en page structurée, vous avez deux instances de D autour, qui ne demandent que des conflits de version.

Answer 4

il y a deux types de choses ici

1. dépendance externe avec les bibliothèques de tiers comme log4j
2. Dépendance interne au sein du projet

idéalement, vous devriez avoir le répertoire lib pour votre intérieur dépendance. vous devez générer dynamiquement la dépendance externe lors de la création du plan de déploiement.

Answer 5

Pour faire écho à une autre réponse, "Pourquoi ne pas utiliser Maven?" Maven va gérer toutes vos dépendances pour vous, et quand un autre projet veut utiliser votre pot, il sera beaucoup, beaucoup plus facile pour eux de le faire. S'il y a un standard pour la construction, la mise en page et les dépendances dans le monde Java, c'est Maven.

Answer 6

Optez pour votre dernière option - répertoire lib plat. C'est ce que vous trouverez si vous téléchargez un projet open source qui a des dépendances (ils peuvent utiliser un autre niveau de sous-répertoire s'il y a un certain nombre de fichiers JAR associés). Ne confondez pas une structure de répertoires avec la gestion des dépendances - ce sont des choses complètement séparées. Si vous voulez une gestion intelligente des dépendances, alors vous devez regarder quelque chose comme Maven, ANT avec Ivy, ou éventuellement un système de modules avec des dépendances explicites (OSGi).

Answer 7

L'information cruciale est comment les classes seront chargées. Dans une situation "java -jar SuperWhizBang.jar", un chargeur de classe chargera toutes les classes. Ensuite, il serait parfaitement logique de fusionner les dépendances.

Si vous choisissez d'avoir des chargeurs de classe séparés, une hiérarchie serait une bonne idée. Cela se produit généralement dans un environnement OSGi, mais cela est probablement exagéré pour votre solution.