Bonjour,
En dehors du problème lié à la taille du fichier ".jar" et aux problèmes liés à la sécurité, pourquoi ne crééez-vous pas de fichier .jar qui centralise à la fois : les binaires, les sources et la javadoc?
Merci et A+
Nicolas.
Version imprimable
Bonjour,
En dehors du problème lié à la taille du fichier ".jar" et aux problèmes liés à la sécurité, pourquoi ne crééez-vous pas de fichier .jar qui centralise à la fois : les binaires, les sources et la javadoc?
Merci et A+
Nicolas.
La question est: qu'est-ce que cela amène?
étant donné que la majorité des projets proposent plusieurs fichiers pour chaque release:
- bin
- src
- doc
- all-in-one
Il ne faut pas oublier le destinataire final du jar.
Est-ce que l'utilisateur lambda d'une application à besoin des sources et de de la javadoc?
Suivant le type de contrat avec le client, les sources ne sont pas toujours livrées.
Salut,
+1Citation:
Envoyé par Pill_S
Les jar sont censés être déployés avec les applications, et donc aux utilisateurs finaux (qui n'ont rien à faire d'avoir la doc ou les sources).
Par contre on retrouve souvent le tout regroupé dans un unique zip contenant le jar, les sources et la docs :mrgreen:
a++
Ca peut servir pour des EDI comme Eclipse. Lors de l'ajout d'une dépendance vers un jar contenant les sources, il est possible de naviguer dans les sources via un Ctrl+Click sur les méthodes/classes contenu dans le jar.
Mais en général, on peut faire 2 versions (un jar sans sources pour le déploiement, un jar avec sources pour le développement).
Par contre, mettre la javadoc dedans... :aie:
Bon pour répondre à la question : je dirais qu'il tout à fait possible de le faire. par contre quelle utilité y a t il à joindre le code source et la javadoc au .Jar?
si on programme une api, la javadoc serait indispensable dans ce cas mais pas le code source sauf si on veut rendre le projet OpenSource.
Par contre si c'est une application, la seule utilité d'inclure la javadoc et le code source, c'est pour sa propre archive de projets!
En conclusion, d'après vos réponses, je pense que la solution la plus élégante (pour mon problème) est d'avoir 4 versions des jars :
--> src;
--> bin (compilée sans mode débug);
--> doc;
--> full (src + bin en mode débug + doc).
La version full sera principallement utilisée pour le développement. Sinon, dans les environnements de production, la version bin sera déployée.
Si les développeur travaillent avec la version Full, ils ne devront pas en cas de besoin retrouver les sources ou encore la javadoc correspondant à la version de leur .jar.
Pour les version src et doc, il n'y a aucune utilité à les mettre dans un jar, un zip ou tout autre format d'archive (rar) est plus approprié.