Distribuion Java sous forme de fichier jar contenant la configuration, les librairies et les sauvegardes

Question

Je suis en train de développer un framework qui nécessite beaucoup de choses pour fonctionner. J'ai plusieurs dossiers à l'intérieur de mon projet Eclipse qui sont nécessaires

[root]
- config
- src
- lib
- serialized

Il y a aussi des fichiers importants comme le log4j.properties et le META-INF dir dans le répertoire src.

Je me demande s'il existe un moyen de distribuer un fichier JAR contenant tous les fichiers essentiels afin que mon interface graphique ne doive importer qu'un seul fichier. Je suppose que je dois exclure le dossier config afin de rendre le framework configurable.

Je me demande aussi, s'il y a un moyen de déplacer par exemple le log4j.properties au répertoire config afin que j'ai un dossier de configuration contenant toutes les configurations nécessaires?

Merci de votre aide et de vos conseils à ce sujet!

Marco

Answer 1

Oui, mais pas vraiment. Vous pouvez prendre toutes vos dépendances, les décompresser et les fusionner simplement dans un pot plus grand. C'est ce que fait le plugin maven jar si vous faites un jar avec des dépendances. Le seul problème est que cela peut entraîner des fichiers en conflit (supposons que deux de vos dépendances contiennent un fichier log4j.properties). C'est l'un des problèmes en faisant ce qui précède avec certaines des bibliothèques de printemps par exemple.

Je pense que quelqu'un a réellement écrit un chargeur de classe qui vous permet de regrouper tout le pot à l'intérieur de votre pot et de l'utiliser tel quel. Je ne suis pas sûr de la maturité et je ne peux pas rappeler le nom pour le moment.

Je pense que vous êtes mieux de distribuer toutes vos dépendances séparément. Mettre en place le classpath est un peu pénible mais sûrement les programmeurs java sont habitués à ça maintenant. Vous pouvez ajouter des dépendances au Class-Path header in your manifest file, dans des cas simples. Les plus grandes bibliothèques doivent cependant s'appuyer sur le classpath qui leur est configuré. En ce qui concerne la deuxième partie de votre question, il est probable que la suppression du répertoire conf/sous META-INF suffise pour récupérer son contenu. Je ne suis pas sûr de cela. Je suis à peu près sûr qu'il sera toujours ramassé si vous mettez son contenu au niveau supérieur du pot. En tout cas, c'est un problème de distribution. Vous pouvez facilement avoir un répertoire conf/ à l'intérieur de votre arborescence source et avoir vos scripts de construction (peu importe ce que vous utilisez) copiez les fichiers à l'endroit le plus pratique.

En ce qui concerne la configuration de vos utilisateurs. Essayez d'établir quelques conventions afin qu'ils doivent configurer le moins possible. Pour les choses qui doivent être configurées, il est préférable d'avoir une configuration par défaut de base, puis de permettre à l'utilisateur de surcharger et d'ajouter des options via son propre fichier de configuration.

Answer 2

En termes de ressources, c'est possible sauf que si vous faites cela, vous ne pourrez pas charger de ressources (fichiers non-classe) à partir du système de fichiers (via un chemin de fichier).

Il est probable que vous chargiez actuellement ces ressources à partir du système de fichiers. Une fois dans le fichier, vous devez les charger en tant que ressources de chemin de classe via class.getResourceAsStream ou similaire.

En ce qui concerne les jarres dépendantes que vous pouvez avoir, il est de pratique courante de les placer comme jarres supplémentaires sur le chemin de classe. Je sais que cela complique les choses, mais les développeurs ont l'habitude de le faire. La nature du paysage java est que c'est inévitable.Ce que le cadre de printemps par exemple fournit un fichier zip fourni avec le pot de base et les dépendances de jar inclus.

Votre bibliothèque va-t-elle être utilisée dans un contexte EE ou dans un contexte SE? Si c'est un contexte EE, vous n'avez vraiment pas à vous inquiéter des problèmes de configuration et de chemin de classe car le conteneur s'en occupe. Dans un contexte SE, c'est beaucoup plus compliqué car ce travail doit être fait manuellement.