Le 30 décembre 2011 23:12, Yves Martin <ymartin59@???> a écrit :
> 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.
Je ne vois pas en quoi ça améliore la fiabilité. La facilité de
déploiement probablement, mais je ne vois pas ce qu'il y a de plus
fiable que d'utiliser un ensemble de bibliothèques réellement validées
par les développeurs de l'application. Gagner en simplicité de
déploiement et en espace disque oui, mais en fiabilité je ne vois pas
pourquoi.
Je voudrais aussi faire remarquer que les questions de dépendances
n'existent pas qu'en Java et il est souvent nécessaire d'envoyer un
tas d'information sur ce qui est installé sur une machine pour pouvoir
remonter un bug (je crois par exemple que reportbug de Debian envoie
la liste des paquets installés).
> --
> Yves Martin
>
>
>
_____________________
Michel BARRET
