On Fri, 2011-12-30 at 13:24 +0100, Jerome Kieffer wrote:
> Au taff on me considere souvent comme un anti-java primaire car je considere que "dezipper dans un coin" c'est mal.
> Suis-je le seul choqué par ce type de pratique ?
> Si java est tellement supérieur au reste, comment se fait ils qu'il soit si foncièrement incompatible avec le reste du monde (libre au moins) ?
>
> Ce n'est pas qu'un troll, j'aimerais bien comprendre un jour.
Salut Jérôme,
En tant que professionnel Java, j'aimerais tenter un éclairage sous
forme d'anecdotes.
J'ai été agréablement surpris de trouver un RPM "Eclipse" sur Mandriva
en 2008 je crois et quelques plugins en RPM. Ils n'ont jamais été mis à
jour depuis. Donc j'ai supprimé le RPM et récupéré le "zip" des
nouvelles versions...
Et finalement l'intérêt d'un package est très limité car ensuite il faut
récupérer des plugins - et ils peuvent être nombreux, que ce soit dans
le cas d'Eclipse ou de Maven. Bref, ces éléments finissent alors dans le
"homedir" de chaque utilisateur...
Ces logiciels ne sont pas conçus pour mutualiser les resources en
respectant les principes Unix et leurs dépendances représentent de
véritables forêts !
Ensuite, la plus récente concerne un projet à qui j'ai conseillé
d'utiliser les RPMs fournis par le projet JPackage
http://jpackage.org/
pour déployer leur application web avec la JVM et un Apache Tomcat sur
RedHat en production.
Au début, cela semblait une bonne idée notamment pour les mises à jour
de sécurité.
Mais voilà, les développeurs travaillant avec le zip du Tomcat 6.0.28
sur leur poste (c'est pas du Linux, vous vous en doutez) ont eu beaucoup
de mal à diagnostiquer un problème se produisant uniquement en
production (RedHat + JPackage) qui est lié à la bibliothèque DBCP en
l'occurrence buggée dont la version 1.2.1 (de 2004 s'il vous plaît !)
est tirée par les dépendances du RPM "tomcat 6.0.28" et qui n'a rien à
voir avec la version incluse dans le zip "officielle" de cette version -
on aurait dû avoir la 1.4 (de 2010).
Et pour comprendre cette bévue, il m'a fallu analyser la chaîne de
compilation de Tomcat pour savoir quelle version exacte de DBCP est
utilisée dans la 6.0.28. Et ce que j'ai découvert n'est pas triste: le
build de Tomcat sélectionne dans les sources les classes des différentes
bibliothèques "commons-pool" et "commons-dbcp" pour faire son propre
"petit bazaar" dans "lib/tomcat-dbcp.jar". Dans quel but ? gagner
quelques kilos, pouvoir appliquer des patchs ? Brouiller les pistes,
c'est réussi.
Vu la difficulté que j'ai eu à retrouver les numéros de versions, je ne
blame pas les créateurs des packages d'avoir réutilisé une veille
dépendance qui "semblait marcher" ou "semblait ne pas avoir changé". Le
problème vient surtout du choix de l'équipe Tomcat de travailler avec
les sources de bibliothèques externes, faisant disparaître la version
des noms des fichiers et des Manifest.
(c'est long, il est temps de conclure sinon je vais y passer le
réveillon)
Les équipes de développement d'application, de serveur ou outils Java
ont de gros problèmes avec les dépendances qui sont à mon goût très mal
décrites dans les "pom" (project object model) de Maven qui est
actuellement la référence. Ça fonctionne assez bien et ça fait gagner
beaucoup de temps mais ce n'est pas parfait: la reproductibilité d'un
build est un exercice périlleux par exemple.
Apache Ivy pourrait améliorer les choses mais il faudra encore ouvrir
les yeux à beaucoup de monde avant que tout soit d'équerre.
Mon idéal: une description de dépendances à la Debian avec des ou/et et
des <= et > sur les versions, des "suggested" et des "recommended", tout
cela accompagnant les classes dans le jar généré.
OSGi pourrait être un début de solution mais c'est lourd et la
vérification des combinaisons de dépendances nécessite beaucoup de tests
automatisés.
Quand on y sera, la construction de package sera facilitée et surtout
fiable. Avant ça, on s'expose à des difficultés que la mise en oeuvre
d'un "zip" qui contient toutes les "bonnes" dépendances évite à peu de
frais.
--
Yves Martin
