Re: Anti-Java primaire

On Fri, 2011-12-30 at 23:25 +0100, Michel wrote:

> > 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.

C'est ce que je voulais dire: le "zip" est fiable parce que les
dépendances sont justes.

L'exemple que je viens de donner avec le Tomcat de JPackage est un échec
évident de fiabilité de la construction des packages, parce que le build
fait des opérations inattendues dont le mainteneur n'a pas (pris)
connaissance.

Et chaque projet Java a ces "petites" spécialités au niveau du build.
C'est loin d'être monotone.

Pour moi, la solution repose sur une standardisation du processus de
build par exemple avec des plugins qui s'occupent de générer les
descripteurs pour .deb et RPM pour que le travail soit juste dès la
source.

Au passage, ce que j'ai vu des packages "java" sur Debian me semble bien
fait - comme toujours.

> 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).

Oui, encore faut-il que les numéros de versions soient clairement
visibles lorsque des dépendances sont utilisées.

Typiquement, le "lib/tomcat-dbcp.jar" ne contient aucune information sur
les versions d'origine de "commons-dbcp" et "commons-pool" qui ont été
utilisées.

Combien de fois j'ai pesté en voyant arriver des "machin.jar" dans un
projet, au lieu de "machin-x.y.jar", quand je n'apprends pas plus tard
que "oui mais on a dû faire un patch pour un bug...". Et ce patch, il
est où ? Le jar est bien dans Subversion mais leur cuisine préliminaire
était sur le point de s'évaporer. Du bon usage des projets OpenSource
dans le monde de l'entreprise - pour faire disparaître le "on prend et
on oublie de participer" !

--
Yves Martin