[LCC] La vérité sur Maven et compagnie

[Frederic Simon]

Dans le dernier épisode et dans certaines discussion sur le groupe, je
trouve le biais pro-Maven assez déroutant! Heureusement Guillaume est
là :)

J'utilise Maven 2 depuis sa sortie en 2005, et après avoir migrer de
nombreux clients, y'à pas photo: Jusqu'à présent y'à pas mieux!
Maven 2 et la gestion globale des dépendances est une révolution dans
notre environnement de travail, et pour rien au monde je retournerais
vers du pure Ant.

Maintenant, le monde idyllique décrit par Vincent et Arnaud est bien
trop éloigné de la réalité, pour que je reste silencieux!
Alors, désolé c'est pas mon style, mais je vais m'énerver :)

Vincent décrit Maven comme une manne divine tomber du ciel sur XWiki,
et sans rien faire tout marche impeccable! Alors qu'il a du développer
plusieurs plugins Maven, ajouter un cycle de vie et configurer sans
relâche ses pom.xml pour les 4 dernières années.
Développer un plugin pour Maven est l'une des plus horrible torture
infligé à un développeur Java:
Collections non typées,
Héritage OO impossible (XDoclet),
Pas d'annotations Java 5,
Pas d'API pour activer les tâches Ant de base,
Une API incompréhensible avec des comportements étranges (récupérer
les dépendances d'un projet selon le scope est une aventure qui change
a chaque version mineure de Maven),
Et une réécriture complète des fonctions de base (navigation de
l'arbre des répertoires, filtre, copie de fichiers, etc...).
Et si en plus, vous voulez changer le cycle de vie (une des fonctions
clé vendu par Maven 2), il faut se taper du Plexus component.xml et
une résolution des versions de plugin bien foireuse.

Maintenant, même au jour le jour, comme bête utilisateur Maven, je
souffre et les gars de Maven s'en foute!
L'un des plus gros problème de Maven 2 avec des gros multi-projet est
http://jira.codehaus.org/browse/MNG-624 une tâche ouverte en 2005,
avec plus de 170 votes! Toujours pas résolue! Raison principale: Faut
pas utiliser Maven comme ça!
Le dernier blog d'Arnaud (http://blog.aheritier.net/construire-moins-
pour-aller-plus-vite/) sur l'activation sélective ne marche que si
l'arborescence des répertoires et des POM sont parfaitement alignées!
Pourquoi: C'est comme ça qu'il faut utiliser Maven!
Si je veux éviter de recréer un jar quand rien ne change (une
fonctionnalité inclus dans Make!), mission quasi impossible! Pourquoi:
C'est comme ça que marche Maven!
Et pour la gestion des dépendances voici un lien très instructif sur
Ivy contre Maven, par des gens intelligents chez JBoss
http://community.jboss.org/thread/89941 ! Mais bon, à la fin, à cause
du manque de compétition, JBoss a choisi Maven :(

Tout ça pourquoi?
Quand Guillaume l'a mauvaise a propos de: "Si j'avais connu Scala
j'aurais pas écrit Groovy!"
De même pour le créateur de Maven: "Si j'avais connu Gradle j'aurais
pas écrit Maven!"
La GROSSE différence est que la dernière phrase est totalement fausse:
- Ivy existait avant Maven 2: C'était et ça reste aujourd'hui le
meilleur gestionnaire de dépendance sur la planète. Écrit par un brave
Français Xavier Hanin en Septembre 2004! Mais bon, moi créateur de
Plexus et Maven 1, je vais pas utiliser un projet écrit par un
Frenchie!
- Ant existait avant Maven 2. Pour ce qui est de la gestion de
fichiers, compilation, création de jar, distribution et exécution a
partir de Java, il n'y pas mieux. C'est robuste et tout le monde
connaît les paramètres et la syntaxe. Mais bon, moi créateur de Plexus
et Maven 1, je peux faire mieux!
- Les concept de DI et IoC existait avant Maven 2. Il y avait déjà de
nombreuses bonne et moins bonne solutions (dont Spring et OSGi), et
ben non! Mais bon, moi créateur de Plexus et Maven 1, je peux écrire
mon DI tout seul!

Et aujourd'hui après tout cette souffrance inutile infligé à ses
compatriotes, le Sir se permet: http://twitter.com/jvanzyl/statuses/12831133458

Alors, s'il vous plaît ouvrez les yeux et venez comparer Gradle le 6
Mai a Paris (http://www.zenika.com/conference/usine_logicielle/
integration_continue_la_totale), et Maven 3 le 11 Mai au Paris JUG
(http://www.parisjug.org/xwiki/bin/view/Meeting/20100511).

A bientôt,
Frederic Simon,
JFrog co-fondateur.

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.
Pour envoyer un message à ce groupe, adressez un e-mail à lescast...@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr

[Guillaume Laforge]

De la balle ce mail :-)

C'est clair que tout n'est pas tout blanc ou tout noir !
Gradle est encore jeune et a besoin de mûrir, certainement, mais Maven
pourrait sans doute être plus souple, car pour les projets
non-triviaux (pas un simple JAR / WAR / EAR), Maven montre ses
limites, alors que l'approche scripting d'un Gradle montre au
contraire sa souplesse.

Enfin bref, un débat interminable, car on aura toujours des
pro-quelque chose et des contres-autre chose, juste par principe :-)
En tout cas, c'est bien de mettre en lumière que tout n'est pas rose,
ni avec l'un, ni avec l'autre, mais qu'il y a besoin de nuance !

Merci Fred,

Guillaume

2010/4/26 Frederic Simon <frederi...@gmail.com>:

--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one

[Henri Gomez]

Tout n'est pas rose dans le monde réel, pas plus dans l'OpenSource
chez Apache ou autre.

Cela dit tu évoques là un point très important, voir capital, sur la
gestion et la direction de Maven.

Est-ce un processus communautaire ou unique et mené par une seule et
même personne (voir entreprise) ?
La personne dont tu parles, Jason est bien connu pour ses phrases
définitives, c'est notamment un non ami du projet Tomcat de longue
date.

J'ai une inquiétude réelle et croissante sur Maven, et c'est que ce
projet devienne un pur produit Sonatype décidé, développé et géré par
une entreprise et plus par une communauté.

Si tel est le cas, un fork se produira fatalement ou les utilisateurs
basculeront vers des solutions plus 'participatives'.

Et c'est un convaincu de Maven qui le dit :(

[Julien Viet]

Je pense qu'il serait interessant de faire un comparaison des build
system par leur coûts effectifs en fonction de la taille du projet
(petit, moyen, gros, énorme) et de sa complexité (simple que des jar -
> tordu avec du packaging de folie)

Comme pour Vincent je vois le build comme un mal nécéssaire et ce qui
m'interesse c est le coût global qui comprend (j'en oublie surement),
un peu comme pour ma voiture, j'ai un coût global (achat, maintenance,
location de place de parking, indisponibilité, etc...)

- mise en place initiale
- maintenance / rajouts de modules / fonctionnalités
- disette pour les équipes de travail (qui ne peuvent pas bosser car
le build est cassé)
- performance (un build qui dure 10s coûte moins qu'un build qui dure
100s pour chaque developpeur)

Le coût doit surement varier selon le taille du projet, sa complexité,
les gens qui l'utilisent, etc...

Chaque build a ses avantages et ses défauts, une telle comparaison
nous permettrait de mettre cotés ces différences religieuses et de
voir au fond ce qui est le plus efficace.

[Vincent Massol]

Salut,

Tu as le droit de ne pas aimer Maven et de ne pas l'utiliser. Moi
j'adore et je n'ai rien trouve de toute ma carrière qui s'en approche
au point de vue rapport qualités/inconvénient (pour le build). Si je
trouve mieux je change.

Ce qui me parait évident c'est qu'il répond plutôt mieux que bcp au
besoin au vu du nb de personnes qui l'utilisent. Après tu as le droit
d'utiliser autre chose :)

Je ne relèverai pas les points complètement faux et l'argumentaire
incorrect vis a vis de Ant et Ivy (je suis en vacances et sur un
telephone ce qui tu l'avouera n'est guère confortable ;))

Sent from my iPhone

On 26 avr. 2010, at 12:23, Frederic Simon <frederi...@gmail.com>
wrote:

> es lescastcodeurs.
> Pour envoyer un message à ce groupe, adressez un e-mail à lescastcodeurs@googlegroups.c
> om.
> Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeurs+unsubscribe@googlegroups.c

[nicolas de loof]

Juste qq réponse en ligne (à la fin), vu que je n'ai jamais caché mon point de vue "en dehors de la ligne officielle du parti" sur Maven

La conception de Maven 2 a été élaborée sur la base du demi-échec de maven 1 en terme de maintenabilité. La structure du repo et du code associé a mis du temps à aboutir. C'est sans doute pour ça que des idées nouvelles comme ivy sont passées inaperçues, faute de savoir où elles mèneraient. Je regrette pour ma part que des mécanismes éprouvés comme l'apt de debian n'ait pas été plus étudiés pour reprendre qq bonnes idées.

Ceci-dit, le principal défaut de maven2 pour la gestion des dépendances est la mauvaise qualité des métadonnées, et ça tu ne peux pas le reprocher à Maven. Par contre il y a des fonctionnalités clé qui manquent clairement : exclusions globales, désactivation de la transitivité sur un <dependency>, etc ...

 

- Ant existait avant Maven 2. Pour ce qui est de la gestion de
fichiers, compilation, création de jar, distribution et exécution a
partir de Java, il n'y pas mieux. C'est robuste et tout le monde
connaît les paramètres et la syntaxe. Mais bon, moi créateur de Plexus
et Maven 1, je peux faire mieux!

Tout à fait d'accord, Plexus-utils c'est à peut près la même chose que les apache commons-* mais avec des bugs différents. Dans l'esprit "Not Invented Here" ! Par ailleurs, étant en dehors du SVN Maven, ces composants n'encouragent pas la mutualisation intelligente entre plugins.

 

- Les concept de DI et IoC existait avant Maven 2. Il y avait déjà de
nombreuses bonne et moins bonne solutions (dont Spring et OSGi), et
ben non!  Mais bon, moi créateur de Plexus et Maven 1, je peux écrire
mon DI tout seul!

Plexus est issu d'Apache Avalon, très antérieur à Spring sur l'IoC. Sur ce coup je regrette perso que Spring n'ait pas été choisi, mais à l'époque des premiers devs Maven2 ce n'était qu'une version 0.5, dont l'avenir n'était pas du tout évident. Evidemment, le fait que Jazon est travaillé dessus a été un facteur décisif, mais Plexus n'a pas été écrit POUR Maven (au moins au début) pour remplacer un concurrent en DI. 

 

Et aujourd'hui après tout cette souffrance inutile infligé à ses
compatriotes, le Sir se permet: http://twitter.com/jvanzyl/statuses/12831133458

Sur ce sujet je n'en ajouterais pas des tones. Jason est talentueux, inventif, mais clairement pas un homme de communication et a le don pour envoyer braire tout ceux qui ne pensent pas comme lui. 

 

Alors, s'il vous plaît ouvrez les yeux et venez comparer Gradle le 6
Mai a Paris (http://www.zenika.com/conference/usine_logicielle/
integration_continue_la_totale), et Maven 3 le 11 Mai au Paris JUG
(http://www.parisjug.org/xwiki/bin/view/Meeting/20100511).

Avec plaisir ;)

 

A bientôt,
Frederic Simon,
JFrog co-fondateur.

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.
Pour envoyer un message à ce groupe, adressez un e-mail à lescast...@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr

[Romain Pelisse]

Et pour la gestion des dépendances voici un lien très instructif sur
Ivy contre Maven, par des gens intelligents chez JBoss
http://community.jboss.org/thread/89941 ! Mais bon, à la fin, à cause
du manque de compétition, JBoss a choisi Maven :(

Et je pense que JBoss le regrette ou la du moins paye cher. Le retour de sortie de JBoss 5.x a comme cause, parmi d'autres of course, le passage sous Maven. J'ai aussi un ancien collègue chez JBoss qui a essayer de porter son projet sur Maven 2, et ça c révéler tellement complexe que ça a tuer le projet ! 

 

Par contre je pense que la "morale" sur Maven donnée par les Cast Codeurs est la bonne : "Maven 2, c'est très si ton projet est aligné dessus ou relativement standard, mais probablement un enfer si ton projet sors du moule". 

D'une manière générale, si le projet sort du moule, Ant apporte une souplesse bien appréciable surtout si on le couple avec Ivy pour profiter des avantages indéniables d'un gestionnaire de dépendances. 

--
Romain PELISSE,
"The trouble with having an open mind, of course, is that people will insist on coming along and trying to put things in it" -- Terry Pratchett
http://belaran.eu/

[nicolas de loof]

Tu peux aussi poser la question dans l'autre sens : pourquoi ton projet sort-il "autant" du moule ?

Est-ce que tu développe vraiment un truc tellement innovant que tu déroge à la structure de base genere-code, compile, test, package ?

J'ai moi aussi "subi" une migration délicate, mais ce qui en est sorti c'est qu'on avait monté - via une foultitude de taches Ant - une usine à gaz (compilation en trois passe, java 1.3 puis java 5, puis RE-java 1.3 ... ). En pratique, en dehors du build, même les devs étaient monstrueux car Eclipse non plus ne pouvait pas s'en sortir tout seul (non, IDEA n'aurait pas fait mieux sur ce coup là)

au final, j'ai redécoupé le truc à la Maven, il en est sorti 5 modules spécifiques, et maintenant on arrive à compiler le bouzin et à bosser sereinement sous Eclipse.

[Guillaume Laforge]

2010/4/26 nicolas de loof <nicolas...@gmail.com>:

> Tu peux aussi poser la question dans l'autre sens : pourquoi ton projet
> sort-il "autant" du moule ?

Typiquement, quand tu penses à un projet comme un langage, qui doit se
builder lui-même (bootstrapping du compilateur, etc), là c'est un truc
qui sort du moule standard.

> [...]

--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one

[nicolas de loof]

1. C'est pas le plus courant !

2. sauf erreur de ma part (je ne pratique pas beaucoup la création de nouveaux langages), dans ce cas on construit d'abord le mini-compilo qui permet de construire le compilo (c'est bien ça le "bootstrapping" ?). Dans ce cas, pourquoi ne pas avoir 2 modules maven différents pour ces deux "artefacts" ? Juste parce que 2 répertoire c'est pas joli ?

[Guillaume Laforge]

2010/4/26 nicolas de loof <nicolas...@gmail.com>:

> 1. C'est pas le plus courant !

C'est clair :-)
Mais ça fait parti des 20% de projets pour lesquels Maven est plus un
coût qu'un gain.

> 2. sauf erreur de ma part (je ne pratique pas beaucoup la création de
> nouveaux langages), dans ce cas on construit d'abord le mini-compilo qui
> permet de construire le compilo (c'est bien ça le "bootstrapping" ?). Dans
> ce cas, pourquoi ne pas avoir 2 modules maven différents pour ces deux
> "artefacts" ? Juste parce que 2 répertoire c'est pas joli ?

Oui, c'est clair, on pourrait (et on fera certainement bientôt) deux
modules pour ça.
Mais ce n'est que la partie visible de l'iceberg.
Il y a d'autres aspects sur les artefacts qu'on génère, etc, qui font
qu'on tordrait un peu trop Maven pour qu'il fasse vraiment tout ce
qu'on veut.
Quoi qu'il en soit, pour un projet comme Groovy, on aurait besoin de
plus de modules (c'est pas vraiment le problème), et surtout tout un
tas d'étapes intermédiaires en plus avec l'aide de plugins customs
pour chacune.

Guillaume

[nicolas de loof]

Quoi qu'il en soit, pour un projet comme Groovy, on aurait besoin de
plus de modules (c'est pas vraiment le problème), et surtout tout un
tas d'étapes intermédiaires en plus avec l'aide de plugins customs
pour chacune.

des plugins spécifiques + un custom lifecycle, isn't it ?

Pour faire ça, c'est clair que le format XML est chiant, mais finalement ça montre aussi que Maven reste assez adaptable (mais pas à coût 0). Une fois ce squelette en place, le reste roule. L'exemple de Flex-mojos est assez parlant car il rejoint un peu ton cas : de mémoire les premières versions étaient assez infernales avec plein de plugins est d'extension à ajouter. Aujourd'hui, il suffit de mettre <packaging>swc</>

[Guillaume Laforge]

2010/4/26 nicolas de loof <nicolas...@gmail.com>:
>>

>> Quoi qu'il en soit, pour un projet comme Groovy, on aurait besoin de
>> plus de modules (c'est pas vraiment le problème), et surtout tout un
>> tas d'étapes intermédiaires en plus avec l'aide de plugins customs
>> pour chacune.
>
> des plugins spécifiques + un custom lifecycle, isn't it ?
> Pour faire ça, c'est clair que le format XML est chiant, mais finalement ça
> montre aussi que Maven reste assez adaptable (mais pas à coût 0). Une fois
> ce squelette en place, le reste roule. L'exemple de Flex-mojos est assez
> parlant car il rejoint un peu ton cas : de mémoire les premières versions
> étaient assez infernales avec plein de plugins est d'extension à ajouter.
> Aujourd'hui, il suffit de mettre <packaging>swc</>

En tout cas, je dis pas que c'est impossible avec Maven 2 !
Tout est possible, mais effectivement, à quel prix...
Alors qu'avec Gradle, l'aspect scripting et intégration avec Ant et
Maven rends les choses plus simples et plus souples.
Et d'ailleurs, les builds "standards" aussi sont beaucoup moins
verbeux qu'avec Ant ou Maven, grâce aux divers plugins déjà existatns.

[Arnaud Héritier]

Je me lance dans les réponses ..

Arnaud Héritier
Software Factory Manager
eXo platform - http://www.exoplatform.com
---
http://www.aheritier.net

2010/4/26 Frederic Simon <frederi...@gmail.com>

Dans le dernier épisode et dans certaines discussion sur le groupe, je
trouve le biais pro-Maven assez déroutant! Heureusement Guillaume est
là :)

Peut être que le message dans les CC n'est pas clair mais je me trouve pourtant très lucide et objectif par rapport à Maven. C'est loin d'être le monde des bisounours et la solution miracle à tous les problèmes. C'est en partie ce que l'on a décrit dans le livre avec Nicolas et ceux qui ont pu venir à mes sessions sur le sujet aux JUGs doivent pouvoir confirmer que je casse aussi du sucre dessus.

 

J'utilise Maven 2 depuis sa sortie en 2005, et après avoir migrer de
nombreux clients, y'à pas photo: Jusqu'à présent y'à pas mieux!

Complètement d'accord et on en est bien tous là.

 

Maven 2 et la gestion globale des dépendances est une révolution dans
notre environnement de travail, et pour rien au monde je retournerais
vers du pure Ant.

Maintenant, le monde idyllique décrit par Vincent et Arnaud est bien
trop éloigné de la réalité, pour que je reste silencieux!
Alors, désolé c'est pas mon style, mais je vais m'énerver :)

Vas-y laches toi.

 

Vincent décrit Maven comme une manne divine tomber du ciel sur XWiki,
et sans rien faire tout marche impeccable! Alors qu'il a du développer
plusieurs plugins Maven, ajouter un cycle de vie et configurer sans
relâche ses pom.xml pour les 4 dernières années.

Je pense que Vincent n'y passe aujourd'hui qu'une partie infime de son temps. Tout comme moi il a du y passer du temps à son arrivée (j'en passe encore bcp chez eXo). Mais une fois que c'est en pla ce en général ça roule.

Par contre que cela soit Vincent ou moi, nous ne sommes pas du tout représentatifs de l'utilisateur standard du produit.

 

Développer un plugin pour Maven est l'une des plus horrible torture
infligé à un développeur Java:
Collections non typées,
Héritage OO impossible (XDoclet),
Pas d'annotations Java 5,
Pas d'API pour activer les tâches Ant de base,
Une API incompréhensible avec des comportements étranges (récupérer
les dépendances d'un projet selon le scope est une aventure qui change
a chaque version mineure de Maven),
Et une réécriture complète des fonctions de base (navigation de
l'arbre des répertoires, filtre, copie de fichiers, etc...).
Et si en plus, vous voulez changer le cycle de vie (une des fonctions
clé vendu par Maven 2), il faut se taper du Plexus component.xml et
une résolution des versions de plugin bien foireuse.

Je suis complètement d'accord que l'écriture des plugins n'est pas une chose simple à cause de la mauvaise documentation, des APIs plus que critiquables et des techno exotiques. Maven 3 apporte pas mal de changements à ce niveau là (APIs plus simples, puissantes et concises, Google Guice à la place de plexus ..). Espérons que le pari soit tenu pour le bien de la communauté.

Comme l'a dit Nicolas beaucoup de choses sont historiques. Et oui Spring n'étaient pas celui que l'on connait aujourd'hui. La palanquées de bugs tirées des 3 milliards de dépendances que l'on ne contrôlait pas dans Maven 1 nous a vite refroidit et l'écosystème a été refermé. Ensuite oui Jason aime bien ré-ecrire. On peut le critiquer autant qu'on veut mais sans lui et le temps qu'il a passé dessus, Maven ne serait pas là. Y aurait-il autre chose de mieux ? Personne ne le saura.

Après pour es sujets comme les annotations, Java 5 etc, et oui on ne va pas très vite, mais nous ne faisons que refléter la réalité des entreprises.

 

Maintenant, même au jour le jour, comme bête utilisateur Maven, je
souffre et les gars de Maven s'en foute!
L'un des plus gros problème de Maven 2 avec des gros multi-projet est
http://jira.codehaus.org/browse/MNG-624 une tâche ouverte en 2005,
avec plus de 170 votes! Toujours pas résolue! Raison principale: Faut
pas utiliser Maven comme ça!

Perso j'avoue ne toujours pas comprendre ce problème. Oui c'est chiant à la création du projet de recopier les versions à tous les niveaux mais ensuite avec les plugins versions et/ou release, ça ne se voit plus ?

 

Le dernier blog d'Arnaud (http://blog.aheritier.net/construire-moins-
pour-aller-plus-vite/) sur l'activation sélective ne marche que si
l'arborescence des répertoires et des POM sont parfaitement alignées!
Pourquoi: C'est comme ça qu'il faut utiliser Maven!

Non je ne suis pas d'accord. Si ca ne marche pas c'est qu'il y a un bug qui doit etre corrigé.

 

Si je veux éviter de recréer un jar quand rien ne change (une
fonctionnalité inclus dans Make!), mission quasi impossible! Pourquoi:
C'est comme ça que marche Maven!

Maven 3 va aider la dessus, mais effectivement avec l'archi de Maven 2 c'était quasi impossible.

 

Et pour la gestion des dépendances voici un lien très instructif sur
Ivy contre Maven, par des gens intelligents chez JBoss
http://community.jboss.org/thread/89941 ! Mais bon, à la fin, à cause
du manque de compétition, JBoss a choisi Maven :(

Oui Ivy est très bien et je regrette que Maven est réinventé la roue sur ce genre de sujet. Je peux cependant confirmer que Maven 3 a grandement améliorer les choses. 

Tout ça pourquoi?
Quand Guillaume l'a mauvaise a propos de: "Si j'avais connu Scala
j'aurais pas écrit Groovy!"
De même pour le créateur de Maven: "Si j'avais connu Gradle j'aurais
pas écrit Maven!"
La GROSSE différence est que la dernière phrase est totalement fausse:
- Ivy existait avant Maven 2: C'était et ça reste aujourd'hui le
meilleur gestionnaire de dépendance sur la planète. Écrit par un brave
Français Xavier Hanin en Septembre 2004! Mais bon, moi créateur de
Plexus et Maven 1, je vais pas utiliser un projet écrit par un
Frenchie!

Oui et non. Oui c'est du genre à Jason mais perso je pense que l'on avait tous eu notre claque des xxx libs de maven 1 qui nous avaient apportées plus d'ennuies qu'autre chose.

Mais oui pour le cas précis de la réutilisation d'Ivy  je trouve cela dommage car c'est très puissant et stable depuis longtemps

- Ant existait avant Maven 2. Pour ce qui est de la gestion de
fichiers, compilation, création de jar, distribution et exécution a
partir de Java, il n'y pas mieux. C'est robuste et tout le monde
connaît les paramètres et la syntaxe. Mais bon, moi créateur de Plexus
et Maven 1, je peux faire mieux!

Ouai enfin Ant si ils nous avaient écouté et fournit une API au dessus de leurs services et non pas uniquement un modèle lié à leur usage cela aurait été pratique.

Car pour copier un fichier être obligé de créer un faux project ça craint. Sinon oui je suis d'accord, c'est dommage d'avoir du recoder tout cela dans plexus-utils

 

- Les concept de DI et IoC existait avant Maven 2. Il y avait déjà de
nombreuses bonne et moins bonne solutions (dont Spring et OSGi), et
ben non!  Mais bon, moi créateur de Plexus et Maven 1, je peux écrire
mon DI tout seul!

Cf Nico, c'est faux

 

Et aujourd'hui après tout cette souffrance inutile infligé à ses
compatriotes, le Sir se permet: http://twitter.com/jvanzyl/statuses/12831133458

Et oui du grand Jason ... Sur la forme c'est complètement regrettable pour un leader de communauté mais c'est comme ca et on y changera rien

Sur le fond il a pas completement tord, et je pense que tu as le même soucis avec Artifactory. Avoir un bug avec juste marqué ca marche pas, ca aide pas bcp.

Pour ce problème précis, la partie multi-threadée est en cours de dev et on découvre pas mal d'impacts notamment sur la conception des plugins. Aujourd'hui même si le noyau devrait être prêt d'ici peu, cela ne sera pas utilisable avant un certain temps afin que les plugins soient à jour.

 

Alors, s'il vous plaît ouvrez les yeux et venez comparer Gradle le 6
Mai a Paris (http://www.zenika.com/conference/usine_logicielle/
integration_continue_la_totale), et Maven 3 le 11 Mai au Paris JUG
(http://www.parisjug.org/xwiki/bin/view/Meeting/20100511).

J'aurai adoré mais c'est le jour où je peux pas. Je suis deg. Mais si certains y vont je veux bien qu'on en rediscute sur cette mailing liste.

 

A bientôt,
Frederic Simon,
JFrog co-fondateur.

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.
Pour envoyer un message à ce groupe, adressez un e-mail à lescast...@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr

[Arnaud Héritier]

Comme je peux le dire lors de mes prezs, meme si cette opinion est personnelle je ne pense pas et ne souhaite pas que Maven sache adresser 100% des problématiques de builds de la terre entiere.

Déjà si il en faisait 80% qui seraient relativement uniformisées (JEE & co) ça serait super.

Je laisse sans aucun soucis les 20% restant a n'importe quel autre outil plus souple.

Arnaud Héritier
Software Factory Manager
eXo platform - http://www.exoplatform.com
---
http://www.aheritier.net

2010/4/26 Guillaume Laforge <glaf...@gmail.com>

[Arnaud Héritier]

C'est toujours le risque

Aujourd'hui on voit très bien qu'un projet full opensource a bcp de mal a vivre.

Ils sont devenus trop complexes et la compétition avec ceux adossés à des entreprises est infernale.

On le voit par exemple avec le gestionnaire de repositories Archiva (Apache) qui ne tient pas la route face à Artifactory (JFrog) et Nexus (Sonatype).

Il faut un équilibre. Nous avons besoin de ses ressources temps plein mais il faut que la communauté garde le contrôle (ce qui est vérifié par la fondation Apache)

Arnaud Héritier
Software Factory Manager
eXo platform - http://www.exoplatform.com
---
http://www.aheritier.net

2010/4/26 Henri Gomez <henri...@gmail.com>

[nicolas de loof]

- Ivy existait avant Maven 2: C'était et ça reste aujourd'hui le
meilleur gestionnaire de dépendance sur la planète. Écrit par un brave
Français Xavier Hanin en Septembre 2004! Mais bon, moi créateur de
Plexus et Maven 1, je vais pas utiliser un projet écrit par un
Frenchie!

Juste pour la petite histoire, j'ai discuté avec le Xavier en question de l'opportunité de mutualiser des choses entre iVy et mercury (la gestion des artefacts dans Maven 3). Dans l'esprit, il serait OK, dans la lignée Apache. Reste que - comme moi - il trouve assez dommage qu'on ait été débaucher les gars de Jetty (je dis ça de mémoire, je me trompe peut être) pour re-écrire tout le truc alors qu'on avait déjà qq chose qui marche sous la main... 

C'est un peu ça aussi le double effet JVZ : il aime bien bosser avec ses copains (ça n'a rien d'étonnant) mais du coup ça ne colle pas nécessairement avec l'esprit qu'on (moi en tout cas) pourrait attendre d'un projet Apache.

Enfin, pour les débats sur celui qui a le plus gros script (je suis sur que Guillaume va nous faire une blague avec ça), je n'aime pas comparer Maven à Ant ou Gradle sur ce point : les deux derniers sont des outils de script, par définition visant à faire des choses puissantes en qq lignes. Maven vise à standardiser un mécanisme générique, quitte à faire de fichiers plus longs. C'est un peut comme le jeu du programme illisible en Perl qui tient sur une seule ligne. C'est peut être chouette, mais ça n'apporte pas grand chose. 

[Arnaud Héritier]

Le problème de la migration vers Maven est le coût caché de la réarchitecture des projets.

Effectivement pour faire un serveur d'app je ne suis pas certain que perso j'aurai choisi Maven.

Maven apporte des contraintes (plus ou moins comprises/compréhensibles) mais surtout il permet de mettre en avant des qualité ou défaut dans l'architecture.

Enfin Maven offre bcp de puissance qui souvent sont mal utilisées (mauvaise docs, mauvaise compréhension, esprits tordus) et qui donnent des builds sur-architecturés, et sans queue ni tête.

Combien de fois ai-je vu pour créer un simple war un projet de 10 modules sans aucune raison ....

2010/4/26 Romain Pelisse <bel...@gmail.com>

[Guillaume Laforge]

2010/4/26 nicolas de loof <nicolas...@gmail.com>:

> [...]

> Enfin, pour les débats sur celui qui a le plus gros script (je suis sur que
> Guillaume va nous faire une blague avec ça),

Et ben non, ce n'est pas une question de longueur, mais de diamètre :-D
A me tendre la perche comme ça... enfin j'veux dire...
M'fin, bref, tu ne paies rien pour attendre mon coquin ;-)

> je n'aime pas comparer Maven à
> Ant ou Gradle sur ce point : les deux derniers sont des outils de script,
> par définition visant à faire des choses puissantes en qq lignes. Maven vise
> à standardiser un mécanisme générique, quitte à faire de fichiers plus
> longs. C'est un peut comme le jeu du programme illisible en Perl qui tient
> sur une seule ligne. C'est peut être chouette, mais ça n'apporte pas grand
> chose.

Alors attention, ne pas confondre non plus scripting avec absence de
conventions, de lisibilité, etc!
Avec Gradle, pour les projets "standards", tu n'as généralement qu'à
dire usePlugin "java", et hop, toutes les targets habituelles sont là
(compile, resource, jar, test, etc). Donc très succient et lisible.
Sans oublier la déclaration des dépendances et compagnie, mais ça,
encore une fois, ça reste plus lisible que du Maven... quoi que le
fait d'ajouter un peu de scripting dans Maven le rends un peu moins
imbittable.

--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one

[Henri Gomez]

> Juste pour la petite histoire, j'ai discuté avec le Xavier en question de
> l'opportunité de mutualiser des choses entre iVy et mercury (la gestion des
> artefacts dans Maven 3). Dans l'esprit, il serait OK, dans la lignée Apache.
> Reste que - comme moi - il trouve assez dommage qu'on ait été débaucher les
> gars de Jetty (je dis ça de mémoire, je me trompe peut être) pour re-écrire
> tout le truc alors qu'on avait déjà qq chose qui marche sous la main...
> C'est un peu ça aussi le double effet JVZ : il aime bien bosser avec ses
> copains (ça n'a rien d'étonnant) mais du coup ça ne colle pas nécessairement
> avec l'esprit qu'on (moi en tout cas) pourrait attendre d'un projet Apache.

JVZ n'utilise pas les autres projets Apache, voir les taille dès que possible.
Je peux en parler pour le projet Tomcat :-(

Débaucher quelqu'un de chez Jetty alors qu'on a un projet équivalent
dans la fondation c'est révélateur de l'esprit de 'groupe' :/

[Guillaume Laforge]

2010/4/26 Henri Gomez <henri...@gmail.com>:
> [...]

> Débaucher quelqu'un de chez Jetty alors qu'on a un projet équivalent
> dans la fondation c'est révélateur de l'esprit de 'groupe' :/

Ah bon, y a un esprit de groupe chez Apache ?
Je croyais que mettre un projet chez Apache c'était juste pour le
marketing, pour avoir le tampon qui fait classe et tout ?
Trop déçu là !

Bon, j'déconne, c'était une blague :-)

--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one

[nicolas de loof]

Le 26 avril 2010 15:17, Guillaume Laforge <glaf...@gmail.com> a écrit :

2010/4/26 nicolas de loof <nicolas...@gmail.com>:

> [...]

> Enfin, pour les débats sur celui qui a le plus gros script (je suis sur que
> Guillaume va nous faire une blague avec ça),

Et ben non, ce n'est pas une question de longueur, mais de diamètre :-D
A me tendre la perche comme ça... enfin j'veux dire...
M'fin, bref, tu ne paies rien pour attendre mon coquin ;-)

> je n'aime pas comparer Maven à
> Ant ou Gradle sur ce point : les deux derniers sont des outils de script,
> par définition visant à faire des choses puissantes en qq lignes. Maven vise
> à standardiser un mécanisme générique, quitte à faire de fichiers plus
> longs. C'est un peut comme le jeu du programme illisible en Perl qui tient
> sur une seule ligne. C'est peut être chouette, mais ça n'apporte pas grand
> chose.

Alors attention, ne pas confondre non plus scripting avec absence de
conventions, de lisibilité, etc!
Avec Gradle, pour les projets "standards", tu n'as généralement qu'à
dire usePlugin "java", et hop, toutes les targets habituelles sont là
(compile, resource, jar, test, etc). Donc très succient et lisible.

En gros c'est l'équivalent d'un import de script Ant, non ?

 

Sans oublier la déclaration des dépendances et compagnie, mais ça,
encore une fois, ça reste plus lisible que du Maven... quoi que le
fait d'ajouter un peu de scripting dans Maven le rends un peu moins
imbittable.

Le format POM.XML de Maven est une honte pour tous ceux qui font du XML, mais faut malheureusement faire avec la rétro-compatibilité. 

J'aimerais bien qu'on arrive à franchir le pas comme l'a fait Spring avec les namespaces pour avoir qq chose de vraiment utilisable, genre un namespace "magique" pour tous les plugins maven officiels  <plugins:compiler source="1.5"> 

mais ça, c'est pas pour tout de suite

 

--

Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one

--

Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.
Pour envoyer un message à ce groupe, adressez un e-mail à lescast...@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr

[nicolas de loof]

Mais non, c'est juste que c'est super facile d'épeler "nic...@apache.org" même quand on parle super mal anglais

en dehors de ça, la fondation apache ne sert pas à grand chose ... :P

[Henri Gomez]

> Mais non, c'est juste que c'est super facile d'épeler "nic...@apache.org"
> même quand on parle super mal anglais
> en dehors de ça, la fondation apache ne sert pas à grand chose ... :P

Urg, c'est pas la grosse frite chez les commiteurs ASF aujourd'hui.
Un peu de positivisme les enfants :)

[Guillaume Laforge]

2010/4/26 nicolas de loof <nicolas...@gmail.com>:
> [...]

>> Alors attention, ne pas confondre non plus scripting avec absence de
>> conventions, de lisibilité, etc!
>> Avec Gradle, pour les projets "standards", tu n'as généralement qu'à
>> dire usePlugin "java", et hop, toutes les targets habituelles sont là
>> (compile, resource, jar, test, etc). Donc très succient et lisible.
>
> En gros c'est l'équivalent d'un import de script Ant, non ?

Si tu considères que les plugins Maven sont aussi des "imports de
script Ant", alors oui :-)
Sinon, non, ce n'est pas un "vulgaire" import de script (en tout cas
pas comme je l'entende).

> [...]

[nicolas de loof]

:D

[nicolas de loof]

Si tu considères que les plugins Maven sont aussi des "imports de
script Ant", alors oui :-)
Sinon, non, ce n'est pas un "vulgaire" import de script (en tout cas
pas comme je l'entende).

Non justement, c'est pour ça que je demande. Ces plugins Gradle me rappellent tellement les plugins Maven 1 ... et leurs défauts (manque d'isolation, interdépendances...)

 

> [...]

--

Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.
Pour envoyer un message à ce groupe, adressez un e-mail à lescast...@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr

[Frederic Simon]

En effet un plugin Gradle est extrêmement plus clair et puissant (sans parler de diamètre :) qu'un plugin Maven.

En quelques mots:

- Un plugin peux venir d'un jar ou d'un script gradle (par URL ou dependance standard),

- Peux être applique a une liste spécifique de projet ou type de projet (les Mixins qui vont manquer tres fortement a Maven 3),

- Peux changer le cycle de vie et ajouter des taches avec dependance a la volee,

- Ajouter tout sorte de script groovy re-utilisable par l'utilisateur dans son build.gradle.

Un example est le plugin Artifactory pour Gradle: Search for build-info-extractor-gradle-1.0-SNAPSHOT.gradle in http://gradle.artifactoryonline.com/gradle/webapp/artifactsearch.html

Pour les commentaires d'Arnaud sur le development de plugins:

- Maven compiler vient juste aujourd'hui de changer la version de javac a 1.5

- JFrog a développé Maven Anno Mojo en Juin 2007 http://sourceforge.net/projects/mvn-anno-mojo/ propose un patch a JVZ... Toujours rien (Pour info Sun web services Maven plugin l'utilise),

- JFrog a développé Jade Plugins qui créer automatiquement un projet Ant fictif pour chaque POM: http://sourceforge.net/projects/jade-plugins/ 

Et j'en passe et des meilleures,

Fred.

2010/4/26 Guillaume Laforge <glaf...@gmail.com>

--
http://freddy33.blogspot.com/
http://www.jfrog.org/
http://twitter.com/freddy33

[elecharny]

Bon, je vais ajouter ma petite pierre...

A part les Maveners des premiers jours (ie, les contributeurs),
utilisant Maven depuis 2005, je pense être un des plus anciens à avoir
souffert le feu de l'enfer.

Il doit être encore possible de googler mon nom et d'y associer Maven
pour trouver quelques traces que j'y ai laissé (http://www.jroller.com/
carlossg/entry/the_black_magic_inside_maven)

C'étais à l'époque maudite de maven 1, où l'on se faisait crever les
yeux à coup de '<' et de '>'.

Jésus sur sa croix, c'était presque du bonheur à côté de ce que l'on a
souffert sur le projet Apache DS...

Bon, c'était jusqu'à ce que l'on bascule sur Maven 2, et plus
précisément sur Maven 2.0.5, la *première* version à peu près
utilisable de Maven.

Depuis, il faut reconnaître que Maven 2 - et bientôt 3 - n'a plus rien
à voir avec le gnome difforme et malfaisant qui crachait du Jelly.

Pour info, notre projet (Apache DS) comprend 7 sous-projets, dans
lesquels se répartissent 61 modules. Il comprend aussi Studio, une
application RCP avec 33 modules. Tout est géré avec Maven 2 (et ça
compile aussi avec Maven 3, j'ai testé , ça m'a pris une heure...).
Il s'agit accessoirement du 5ème lus gros projet Apache, au cas où
vous vous demanderiez s'il est d'une taille suffisante pour offrir un
exemple pertinent.

Grosso-modo, créer un nouveau module (on le fait régulièrement, par
exemple quand on réorganise notre code) ne prend que qq minutes. La
gestion des dépendances, à conditions que les jars soient bien nommés
(ie, utilisent X.Y.Z comme notation de version, et non pas des trucs à
chier debout sur une table comme 2.5.6.SEC01 - merci Spring ! -) est
un jeu d'enfants.

Bizarrement, autant en M1 on a été obligé d'écrire des plugins
cacateux, autant en Maven 2 on s'en est passé, et c'est très bien.
Parce que, là, franchement, débugger un plugin maven, c'est clairement
le début des hémorroïdes...

Sinon, oui, c'est structurant. Pour moi, Maven, c'est le SAP du build.
Revenir à Ant??? Plutôt crever ! Ca marche bien, on n'y touche pas,
quand j'arrive sur un projet géré par Maven, je retrouve mes petits en
qq minutes, alors que quand j'arrive sur un projet géré par un système
de build procédural (à la Ant our Gradle), il faut se toucher le
prépuce un bon moment avant que de comprendre comment ça marche ...)

En conclusion, et il y a 4 ans je ne pensais pas avoir à le dire :
Merci Maven 2 !

[nicolas de loof]

Sinon, oui, c'est structurant. Pour moi, Maven, c'est le SAP du build.

Je suis pas sûr que ce soit un compliment comme comparaison ;)

 

Revenir à Ant??? Plutôt crever ! Ca marche bien, on n'y touche pas,
quand j'arrive sur un projet géré par Maven, je retrouve mes petits en
qq minutes, alors que quand j'arrive sur un projet géré par un système
de build procédural (à la Ant our Gradle), il faut se toucher le
prépuce un bon moment avant que de comprendre comment ça marche ...)

Hum, Guillaume, tu peux faire mieux ?

 

En conclusion, et il y a 4 ans je ne pensais pas avoir à le dire :
Merci Maven 2 ! 

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.
Pour envoyer un message à ce groupe, adressez un e-mail à lescast...@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr

[Guillaume Laforge]

2010/4/26 nicolas de loof <nicolas...@gmail.com>:
>>

>> Sinon, oui, c'est structurant. Pour moi, Maven, c'est le SAP du build.
>
> Je suis pas sûr que ce soit un compliment comme comparaison ;)

Assez véridique, pourtant :-)

>> Revenir à Ant??? Plutôt crever ! Ca marche bien, on n'y touche pas,
>> quand j'arrive sur un projet géré par Maven, je retrouve mes petits en
>> qq minutes, alors que quand j'arrive sur un projet géré par un système
>> de build procédural (à la Ant our Gradle), il faut se toucher le
>> prépuce un bon moment avant que de comprendre comment ça marche ...)
>
> Hum, Guillaume, tu peux faire mieux ?

Perso, j'essaie de ne pas me toucher en public, donc je préfère ne pas
faire de commentaire :-)

Faudrait peut-être arrêter ces allusions sexuelles, on a des dames qui
sont sur le groupe, alors un peu de décence, non mais !

> [...]

--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one

[Frédéric Bouquet]

Moi qui sort de l'école et qui ai tendance me retrouver embarqué dans
des trolls bien velus au sein de mon lug Grenoblois, j'avoue suivre
votre discussion avec grand intérêt.

On dirait presque une guerre de religion comme bien souvent en
informatique. D'un coté, les communautés informatiques font un peu
penser à ce qu'il se passait au moyen âge où, on prenait parti pour un
village ou un autre, en espérant faire le bon choix.
Aujourd'hui, c'est un peu la même chose, on choisi une communauté ou
une autre, en espérant faire le bon choix, mais on a moins de chance
d'y perdre sa tête :)

Du haut de ma faible expérience du métier, j'ai l'impression qu'il y a
avant tout un soucis au niveau du choix de l'outil pour vraiment
arriver à résoudre au mieux notre problème. Ca peut être pour des
raisons politiques, des raisons de compétence, de mauvaise
connaissance, ...
Après, j'ai l'impression que souvent, on en vient à critiquer un outil
pour de mauvaises raisons, souvent parce que l'on ne sait pas vraiment
bien l'utiliser, ou que l'utilisation qu'on en fait ne suit pas la
logique réelle qui a justifié la construction de l'outil. J'ai vu
beaucoup de gens essayer cette année d'utiliser maven comme un outil
de "scripting" à la ant et pester parce que ça ne fonctionnait pas.
C'est un peu comme lorsque je voyais une thésarde parser du xml en
réécrivant son propre parser alors que du dom convenait
parfaitement... En gros, choisir l'outil qui convient, passer un peu
de temps de se former, avant d'aller critiquer sur celui mal choisi
que l'on utilise (et souvent pas correctement).

J'ai l'impression que notre métier (l'informatique) souffre de gros
soucis de communication, de pédagogie et d'un grand manque de
compétence (vis à vis d'un autre thread des castcodeurs surtout)... A
méditer tout ça :)

Fred

[Emmanuel Lecharny]

On 4/26/10 4:07 PM, nicolas de loof wrote:
>>
>> Sinon, oui, c'est structurant. Pour moi, Maven, c'est le SAP du build.
>>
>>
> Je suis pas sûr que ce soit un compliment comme comparaison ;)
>

Ce n'est pas un compliment. C'est juste un fait. Je dis pas que c'est
fun de construire son build avec Maven, il faut être un pervers
polymorphe pour aimer ça (ou un prêtre...). Disons qu'une fois qu'on est
habitué, ça fait moins mal après.

D'un autre côté, cuex qui prétendent qu'ils s'éclatent à écrire leur
build avec ant, alors ce sont de gros politiciens ! Et croyez-moi, du
build avec ant sur de gros projet, je m'en suis cogné (record : 300
sous-projets. 2 semaines pour construire le build. Ca m'aurait sans
doute pris la moitié avec M2).

>
>
>> Revenir à Ant??? Plutôt crever ! Ca marche bien, on n'y touche pas,
>> quand j'arrive sur un projet géré par Maven, je retrouve mes petits en
>> qq minutes, alors que quand j'arrive sur un projet géré par un système
>> de build procédural (à la Ant our Gradle), il faut se toucher le
>> prépuce un bon moment avant que de comprendre comment ça marche ...)
>>
>>
> Hum, Guillaume, tu peux faire mieux ?
>

je crois pas :) Mais il est fort le bougre, alors, qui sait ?

--
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com

[nicolas de loof]

Tout à fait d'accord

chaque outil a ses points forts et ceux qui le connaissent bien savent en tirer un maximum

les autres galèrent... plus ou moins

du coup, on a toujours peur de changer et devoir faire un choix qui n'ai pas universel devient délicat. Qui veut investir des heures à apprendre XXX si c'est pour se tirer une balle dans le pied ?

Résultat, une fois qu'on a fait un choix on a tendance à s'y accroche, d'où les guerres de clocher !

[Henri Gomez]

>> Hum, Guillaume, tu peux faire mieux ?
>
> Perso, j'essaie de ne pas me toucher en public, donc je préfère ne pas
> faire de commentaire :-)

> Faudrait peut-être arrêter ces allusions sexuelles, on a des dames qui
> sont sur le groupe, alors un peu de décence, non mais !

Quel garçon discret :)

[Henri Gomez]

> Résultat, une fois qu'on a fait un choix on a tendance à s'y accroche, d'où
> les guerres de clocher !

Un outil est une réponse à un besoin/problème à un instant donné.

J'ai commencé l'atelier logiciel avec du make/configure et RPM pour
des applications natives.

Puis je suis passé à Ant lors du passage aux premières applications
Java (perdant RPM au passage).

Avec le temps le nombre de projet d'entreprise est passé à plusieurs
dizaines (plus prêt de 200 que 20).

Je commençais à trouver lourdingue la gestion des 200 build.xml, des
ant 'parents' blindés de fonctions utilitaires et la dispersion des
projets sur les IDE de mes développeurs ou le coût d'installation d'un
IDE (avec les variables pointant vers les librairies externes
nécessaires).

Les arguments déterminants ont été la gestion des dépendances,
l'héritage des réglage des pom parents, le coût de démarrage sur un
nouveau projet pour un développeur mais aussi la création d'un
entrepôt de livrable partagé par les équipes de développement et
production.

[Clement Escoffier]

Bonjour,

Alors, j'ai une relativement longue histoire avec Maven.
J'ai commencé Maven avec Maven 1 ... et oui, c'était assez horrible. Mais bon j'étais étudiant, et donc la productivité n'était pas tellement un facteur déterminant (puis on étais jeune, c'était l'époque Matrix, on adorait les truc qui écrivait plein de chose a l'écran...)
J'ai commencé avec Maven 2 autour de 2005 je crois, au début d'Apache Felix. On nous a vendu Apache Maven 2 comme le truc qui allait nous rendre la vie trop facile ... conclusion, apres avoir essuyé de tres nombreux platres (on a toujours un build.xml qui lance le build maven :-)), ouvert des tas de bugs, demystifié le release plugin, des nouveaux types de packaging (bundle)... on a eu quelques choses de potable en 2008. On a de nouveaux des problèmes (de longueur de compilation), donc rien de tres grave.

Bon néanmoins, ca m'a bien formé (ou déformé), et aujourd'hui on utilise Maven meme pour des builds pas forcément évident (avec bootstraping (le framework, qui utilise lui meme), Android, OSGi ...). Ca nous apporte un vrai cadre, ce qui fait que pour demarrer un projet ca nous prend quelques minutes... En gros on a bâti notre propre build process basé sur maven mais aussi Sonar, Artifactory-> Nexus, Hudson ... L'important c'est pas Maven seul, c'est tout le build process... Ce qui importe aussi c'est la pérénité du build.

Dernièrement, on a migré (mon équipe) 3 gros projets de Ant vers Maven. Quand je dis 'gros' je parle de 10 millions de lignes de code pour le plus petit, 10 ans de développement... Les 3 projets avaient des ressemblances:
- utilisait Ant + Ivy
- récursif
- avait développé leur propre glue autour de ca pour gerer les checkout, release ...
- les builds duraient des heures
- les mecs qui avaient concus ces build process sont tous partis un an apres :-)
- quand il y a des modules, il y en a entre 800 et autours de 2000
- ils ont tous redéveloppez des super framework plus maintenus depuis des lustres mais toujours utilisé pour remplacer hibernate, struts ... (c'est fou ce que les gens sont imaginatifs)

Finalement, les developeurs ne comprenaient pas ce que faisait leur build process. Mais vraiment pas ! On a eu le cas d'un module compilé 18 fois dans un meme process (a cause de la récursion)... (c'était vraiment juste pour être sur qu'il était compilé ???). Un des projets avait plusieurs milliers des scripts ruby gérant les checkout, l'imports dans les ide, les releases... Un vrai bonheur ! Des techniques de copies de sources pour casser les cycles a peut prés partout !

Alors oui, la migration a Maven n'a pas était gratuite, pas forcément facile... mais une fois faite, les 3 équipes sont contentes sur la partie build, reporting ... Le temps des build a éte dramatiquement réduit ... La seule partie délicate est le release process. La c'est beaucoup moins réjouissant et ça demande beaucoup plus de raffinements et d'itérations avant d'avoir le 'release process de reve'.

Donc finalement, Maven seul n'est pas forcément la solution, mais ce qui compte c'est l'infrastructure (comme le dit Vincent). Une fois qu'on a quelque chose qui permet de compiler, packager, tracker, releaser, délivrer, et feedbacker correctement et rapidement, alors c'est gagné ! Maintenant, baser cette infra sur Ant, Graddle ou Maven, ca dépend vraiment du projet, de son scope, de son évolution. De mon expérience, je vois qu'Ant sur du long terme c'est pas forcément miraculeux. Maven a l'air de tenir la route (au moins sur quelques années). Je n'ai aucune expérience sur Graddle, mais j'ai hate de voir ce que ca donne. En terme de flexibilité, les trois projets ne suivaient pas de patterns fixes (pourquoi mettre les source dans src alors qu'on peux les mettre dans 'bin'), et l'utilisation de conventions a clairement clarifié certains modules.

Clement

[ehsavoie]

Salut,
Pour avoir du migrer des projets ANT sous Maven on voit bien qu'un build ANT vieillit assez mal.
Pour moi c'est le point limite du scripting, c'est super souple on fait des trucs magiques assez facilement
et 10 ans après on pleure quand il faut maintenir parce que le build est plein d'astuces plus sioux les unes
que les autres. Chacun y a mis sa petite touche perso et le projet n'a plus aucune structure.
Je sais bien que c'est parce que l'équipe n'est pas constituée de super cadors comme les membres de ce groupe ;o)
Maven impose les règles (plus ou moins intelligentes) et c'est tellement galère d'essayer d'en sortir que le dev lambda,
comme moi, ben il reste dans les clous pour traverser.

Emmanuel

----------
Emmanuel Hugonnet
http://www.ehsavoie.com
http://twitter.com/ehsavoie

2010/4/26 Henri Gomez <henri...@gmail.com>

[Henri Gomez]

Sans oublier que Maven ouvre la voie royale au reste de l'usine
logicielle, Hudson, Sonar.

Le 26 avr. 2010 à 20:13, Clement Escoffier
<clement....@gmail.com> a écrit :

>> Pour envoyer un message à ce groupe, adressez un e-mail à lescastcodeurs@googlegroups.c
>> om.
>> Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeurs+unsubscribe@googlegroups.c

>> om.
>> Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr
>>
>
> --
> Vous recevez ce message, car vous êtes abonné au groupe Google Group

> es lescastcodeurs.
> Pour envoyer un message à ce groupe, adressez un e-mail à lescastcodeurs@googlegroups.c
> om.
> Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeurs+unsubscribe@googlegroups.c

[Guillaume Laforge]

2010/4/26 ehsavoie <emmanuel...@gmail.com>:
> [...]

> Pour moi c'est le point limite du scripting, c'est super souple on fait des
> trucs magiques assez facilement

Les limites du scripting... sans aucune convention.
Gradle, c'est pas "que" du scripting, c'est plus que cela, heureusement.

> [...]

--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one

[Jocelyn]

Tiens c'est amusant, j'ai l'impression qu'on va retomber un peu dans
le même genre de discussion que dans le fil ou l'on parlait de
traductions, et de l'implication des développeurs dans la
compréhension de ce qu'ils font. Car ce que je retiens des expériences
que vous racontez, c'est que l'absence de fil conducteur conducteur et
de compréhension profonde de ce que l'on veut obtenir (quel que soit
l'outil utilisé) mène plus ou moins vite à un processus non
maintenable. Untel va modifier le processus pour arranger son problème
sans se soucier des conséquences, tel autre (plus impliqué !) va
incorporer un nouvel outil qu'il aime bien, ...
D'ailleurs c'est peut-être ici que Maven marque le plus de points: là
ou chacun peut bidouiller dans son coin avec un script, avec Maven
c'est tout de suite plus ardu (surtout si l'on n'explique pas aux dev
comment ca marche, mais que l'on en fait une boite noire ou la seule
chose à comprendre, c'est mvn compile - oui je l'ai déjà vu).
Pour conclure je dirais que la solution au cauchemar c'est peut-être
la même que pour d'autres problématiques, et qu'elle n'est pas
technique. Apprendre à communiquer dans une équipe de dev, expliquer
quelles sont les règles et les enjeux du processus, le documenter,
former ceux qui en ont besoin. Ceux qui ont envie de s'impliquer, se
sentant valorisés, vont avoir tendance à respecter ces mêmes principes
s'ils ont à le modifier. Ceux qui n'en ont pas envie, de toutes façons
ne le toucheront pas (ou s'exposeront à une volée de bois vert s'ils
le font à tort et à travers). Je suis un idéaliste ?

On 26 avr, 21:56, Guillaume Laforge <glafo...@gmail.com> wrote:
> 2010/4/26 ehsavoie <emmanuel.hugon...@gmail.com>:

>
> > [...]
> > Pour moi c'est le point limite du scripting, c'est super souple on fait des
> > trucs magiques assez facilement
>
> Les limites du scripting... sans aucune convention.
> Gradle, c'est pas "que" du scripting, c'est plus que cela, heureusement.
>
> > [...]
>
> --
> Guillaume Laforge
> Groovy Project Manager

> Head of Groovy Development at SpringSourcehttp://www.springsource.com/g2one

[Arnauld VM]

J'ai utilisé Ant pendant des années.

Le principal problème que j'avais, c'était la gestion des librairies
et dépendances. Je me suis donc mis à la recherche d'un outil de
gestion des dépendances. Très vite, Maven et Ivy sont apparus comme
solution possibles. Après avoir lu quelques articles comparant les
deux, j'ai choisi Ivy, car il paraissait plus efficace pour les
dépendances.
Depuis lors j'utilise Ant+Ivy et j'en suis très content.

Je n'ai jamais eu le courage de sauter le pas et de passer carrément à
Maven. J'ai quelques builds alambiqués (après quelques années de
'scripting' ant) et très éloignés d'une organisation 'standard' de
projet. En cause : l'ancienneté de certains de ces projets, mais aussi
des étapes de builds parfois très particulières utilisant des tools
externes propres, des tâches Ant programmées en java ...)
De mon expérience, la construction d'un build prend assez de temps sur
un projet, en tout cas dès qu'on n'est pas dans des projets
'reproductibles'. Il est toujours difficile d'expliquer au management
que "non, je ne peux pas livrer cette fonction demain, parce que je
dois régler des problèmes dans mon build" (l'utilité business
avoisinant le zéro). Et les échos que j'entends sur l'utilisation de
Maven dans des cas compliqués ne m'encourage pas à aller dans cette
voie.

Inconvénients principaux de l'option Ant+Ivy :
- on ne suit pas nécessairement de 'conventions' (d'où perte de temps
pour les nouveaux développeurs)
- certains comportements sont pénibles à coder (e.g. exécution
conditionnelle, modification de paramètres)
J'hésite encore à passer à Maven (dont la V3 devrait apparemment
régler certaines choses).
Une autre option découverte récemment serait Gradle (quid du support
Ivy ?). Quelqu'un a un retour d'expérience sur Gradle ?

Une problématique que je n'ai jamais réussi à gérer proprement avec
Ant, c'est d'éviter de recompiler un package Java dont les classes
sont à jour par rapport aux sources. (tout en évitant les problèmes
dûs à l' 'Inlining' des variables constantes (public static final
String XYZ = "xyz";))

[Emmanuel Lecharny]

On 4/27/10 8:43 AM, Jocelyn wrote:
> Tiens c'est amusant, j'ai l'impression qu'on va retomber un peu dans
> le même genre de discussion que dans le fil ou l'on parlait de
> traductions, et de l'implication des développeurs dans la
> compréhension de ce qu'ils font. Car ce que je retiens des expériences
> que vous racontez, c'est que l'absence de fil conducteur conducteur et
> de compréhension profonde de ce que l'on veut obtenir (quel que soit
> l'outil utilisé) mène plus ou moins vite à un processus non
> maintenable. Untel va modifier le processus pour arranger son problème
> sans se soucier des conséquences, tel autre (plus impliqué !) va
> incorporer un nouvel outil qu'il aime bien, ...
>

C'est assez fréquent, effectivement. Le problème du build, c'est que
généralemenent, une fois que ça tourne, on n'y touche plus. Alors au
bout d'un moment, quand il faut y revenir, on a oublié des éléments en
route.

> D'ailleurs c'est peut-être ici que Maven marque le plus de points: là
> ou chacun peut bidouiller dans son coin avec un script, avec Maven
> c'est tout de suite plus ardu (surtout si l'on n'explique pas aux dev
> comment ca marche, mais que l'on en fait une boite noire ou la seule
> chose à comprendre, c'est mvn compile - oui je l'ai déjà vu).
>

Je partage 100% ton opinion sur le fait que Maven étant structurant, il
n'y a plus trop de latitude d'écire le script de la mort qui tue et qui
ne sera pas maintenu, bien évidemment. Cela facilite le passage de
relais, à condition que le suivant dans la chaîne alimentaire comprenne
comment Maven fonctionne. Par contre je ne pense pas que la raison pour
laquelle on évite de toucher à Maven est que c'est ardu : pour moi,
c'est que ce n'est généralement pas nécessaire.

Alors, oui, il y a un coût d'entrée non négligeable. D'un autre côté,
avec le merveilleux livre de notre ami Arnaud, ce coût sera tout a fait
acceptable :)

> Pour conclure je dirais que la solution au cauchemar c'est peut-être
> la même que pour d'autres problématiques, et qu'elle n'est pas
> technique. Apprendre à communiquer dans une équipe de dev, expliquer
> quelles sont les règles et les enjeux du processus, le documenter,
> former ceux qui en ont besoin. Ceux qui ont envie de s'impliquer, se
> sentant valorisés, vont avoir tendance à respecter ces mêmes principes
> s'ils ont à le modifier. Ceux qui n'en ont pas envie, de toutes façons
> ne le toucheront pas (ou s'exposeront à une volée de bois vert s'ils
> le font à tort et à travers). Je suis un idéaliste ?
>

Hmmm. Généralement, en ce qui concerne le Build, une fois construit, je
pense que la règle devrait être : "moins tu touches, mieux c'est".
Simplement parce que on a autre chose à foutre qu'à tuner Maven, dans le
cadre d'un projet normal. Et c'est là que c'est intéressant : à moindre
coût, une fois qu'on comprend comment ça marche, on arrive rapidement à
'torcher' un process de build franchement rapidement, en tout cas plus
rapidement qu'avec ant ou gradle, simplement parce que les concepts ne
changen pa d'un projet à l'autre.

Après, pour l'implication, je pense qu'un ingénieur informaticien un peu
curieux voudra à un moment ou à un autre comprendre comment ça marche.
Dans le cas contraire, ce n'est pas un bon ingénieur informaticien, non ? ;)

En ce qui concerne les besoins spécifiques, par exemple Groovy, ils
feraient bien d'arrêter d'utiliser gradle, il y a maintenant vachement
mieux : scadle, un système build en Scala. eh eh eh eh ;^)

--
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com

[Nicolas Delsaux]

2010/4/26 Henri Gomez <henri...@gmail.com>:

> Sans oublier que Maven ouvre la voie royale au reste de l'usine logicielle,
> Hudson, Sonar.
>

A ce sujet, je trouve vraiment curieux que, dans le dernier épisode,
Nicolas nous parle de switches alambiqués ("-rf", je rêve) dont le
seul objectif est de faire en ligne de commande ce qu'Hudson fait
spontanément : dans un projet multi-module, quand un module est mis à
jour, tous les modules dépendants sont recompilés automatiquement, et
leurs tests exécutés. Les résultats du tests sont alors affichés dans
une vue de type radiateur et envoyés par mail au coupable (en cas
d'erreur).
D'ailleurs,c e serait sympa d'en parler un peu plus dans les
castcodeurs, je trouve, parce que si il y a bien un outil qui a émergé
grâce à maven et qui maintenant en fait bien plus, c'est bien hudson.

--
Nicolas Delsaux

[Julien Viet]

De mon coté un des choses que j'apprécie chez Maven en tant que
developeur c est que mon IDE favori (pas eclipse ni netbeans, mais je
suis sûr qu'ils le font aussi) importe des projet Maven en 2 coups de
cuillères à pot, me trouve toutes les librairies et me permet de faire
du debugging dans les sources jar qui sont trouvés dans le repository.

Les autres build le font surement j'imagine, peut etre pas de maniere
si automatique que Maven, mais quand je charge un project thirdparty
buildé Maven je peux changer facilement la configuration pour qu'il me
genere le jar de source dans mon repo local, alors qu'avec un build
que je ne connais pas, je n'oserais meme pas y toucher.

On Apr 26, 2010, at 9:53 PM, Henri Gomez wrote:

> Sans oublier que Maven ouvre la voie royale au reste de l'usine
> logicielle, Hudson, Sonar.
>
> Le 26 avr. 2010 à 20:13, Clement Escoffier <clement....@gmail.com
> > a écrit :
>
>> Bonjour,
>>
>> Alors, j'ai une relativement longue histoire avec Maven.
>> J'ai commencé Maven avec Maven 1 ... et oui, c'était assez
>> horrible. Mais bon j'étais étudiant, et donc la productivité
>> n'était pas tellement un facteur déterminant (puis on étais jeune,
>> c'était l'époque Matrix, on adorait les truc qui écrivait plein de
>> chose a l'écran...)
>> J'ai commencé avec Maven 2 autour de 2005 je crois, au début

>> d'Apache Felix. On nous a vendu Apache Maven 2 comme le truc qui
>> allait nous rendre la vie trop facile ... conclusion, apres avoir
>> essuyé de tres nombreux platres (on a toujours un build.xml qui
>> lance le build maven :-)), ouvert des tas de bugs, demystifié le

>> release plugin, des nouveaux types de packaging (bundle)... on a eu
>> quelques choses de potable en 2008. On a de nouveaux des problèmes

>> (de longueur de compilation), donc rien de tres grave.

>>
>> Bon néanmoins, ca m'a bien formé (ou déformé), et aujourd'hui on
>> utilise Maven meme pour des builds pas forcément évident (avec

>> bootstraping (le framework, qui utilise lui meme), Android,

>> OSGi ...). Ca nous apporte un vrai cadre, ce qui fait que pour
>> demarrer un projet ca nous prend quelques minutes... En gros on a

>> bâti notre propre build process basé sur maven mais aussi Sonar,
>> Artifactory-> Nexus, Hudson ... L'important c'est pas Maven seul,
>> c'est tout le build process... Ce qui importe aussi c'est la

>> pérénité du build.
>>
>> Dernièrement, on a migré (mon équipe) 3 gros projets de Ant vers
>> Maven. Quand je dis 'gros' je parle de 10 millions de lignes de

>> code pour le plus petit, 10 ans de développement... Les 3 projets
>> avaient des ressemblances:

>> - utilisait Ant + Ivy
>> - récursif
>> - avait développé leur propre glue autour de ca pour gerer les

>> checkout, release ...

>> - les builds duraient des heures
>> - les mecs qui avaient concus ces build process sont tous partis un
>> an apres :-)
>> - quand il y a des modules, il y en a entre 800 et autours de 2000
>> - ils ont tous redéveloppez des super framework plus maintenus

>> depuis des lustres mais toujours utilisé pour remplacer hibernate,

>> struts ... (c'est fou ce que les gens sont imaginatifs)
>>
>> Finalement, les developeurs ne comprenaient pas ce que faisait leur
>> build process. Mais vraiment pas ! On a eu le cas d'un module

>> compilé 18 fois dans un meme process (a cause de la récursion)...

>> (c'était vraiment juste pour être sur qu'il était compilé ???). Un
>> des projets avait plusieurs milliers des scripts ruby gérant les
>> checkout, l'imports dans les ide, les releases... Un vrai
>> bonheur ! Des techniques de copies de sources pour casser les

>> cycles a peut prés partout !

>>
>> Alors oui, la migration a Maven n'a pas était gratuite, pas

>> forcément facile... mais une fois faite, les 3 équipes sont

>> contentes sur la partie build, reporting ... Le temps des build a
>> éte dramatiquement réduit ... La seule partie délicate est le

>> release process. La c'est beaucoup moins réjouissant et ça demande
>> beaucoup plus de raffinements et d'itérations avant d'avoir le

>> 'release process de reve'.
>>
>> Donc finalement, Maven seul n'est pas forcément la solution, mais
>> ce qui compte c'est l'infrastructure (comme le dit Vincent). Une
>> fois qu'on a quelque chose qui permet de compiler, packager,

>> tracker, releaser, délivrer, et feedbacker correctement et
>> rapidement, alors c'est gagné ! Maintenant, baser cette infra sur

>> Ant, Graddle ou Maven, ca dépend vraiment du projet, de son scope,
>> de son évolution. De mon expérience, je vois qu'Ant sur du long

>> terme c'est pas forcément miraculeux. Maven a l'air de tenir la
>> route (au moins sur quelques années). Je n'ai aucune expérience sur

>> Graddle, mais j'ai hate de voir ce que ca donne. En terme de

>> flexibilité, les trois projets ne suivaient pas de patterns fixes
>> (pourquoi mettre les source dans src alors qu'on peux les mettre
>> dans 'bin'), et l'utilisation de conventions a clairement clarifié

>> certains modules.
>>
>> Clement
>>
>>
>>
>> On 26.04.2010, at 17:07, Henri Gomez wrote:
>>
>>>> Résultat, une fois qu'on a fait un choix on a tendance à s'y

>>>> accroche, d'où

>>>> les guerres de clocher !
>>>
>>> Un outil est une réponse à un besoin/problème à un instant donné.
>>>
>>> J'ai commencé l'atelier logiciel avec du make/configure et RPM pour
>>> des applications natives.
>>>
>>> Puis je suis passé à Ant lors du passage aux premières applications
>>> Java (perdant RPM au passage).
>>>
>>> Avec le temps le nombre de projet d'entreprise est passé à plusieurs
>>> dizaines (plus prêt de 200 que 20).
>>>
>>> Je commençais à trouver lourdingue la gestion des 200 build.xml, des
>>> ant 'parents' blindés de fonctions utilitaires et la dispersion des
>>> projets sur les IDE de mes développeurs ou le coût d'installation
>>> d'un
>>> IDE (avec les variables pointant vers les librairies externes
>>> nécessaires).
>>>
>>> Les arguments déterminants ont été la gestion des dépendances,
>>> l'héritage des réglage des pom parents, le coût de démarrage sur un
>>> nouveau projet pour un développeur mais aussi la création d'un
>>> entrepôt de livrable partagé par les équipes de développement et
>>> production.
>>>
>>> --
>>> Vous recevez ce message, car vous êtes abonné au groupe Google

>>> Groupes lescastcodeurs.
>>> Pour envoyer un message à ce groupe, adressez un e-mail à lescast...@googlegroups.com
>>> .

>>> Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com

>>> .
>>> Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr
>>>
>>
>> --
>> Vous recevez ce message, car vous êtes abonné au groupe Google
>> Groupes lescastcodeurs.
>> Pour envoyer un message à ce groupe, adressez un e-mail à lescast...@googlegroups.com
>> .

>> Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com

>> .
>> Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr
>>
>
> --
> Vous recevez ce message, car vous êtes abonné au groupe Google
> Groupes lescastcodeurs.
> Pour envoyer un message à ce groupe, adressez un e-mail à lescast...@googlegroups.com
> .

> Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com

[Frédéric Bouquet]

La discussion me fait penser un peu à l'image du débat : acheter une
paire de chaussures à 20 euros tous les 3 mois ou acheter une paire de
chaussure 100 euros tous les deux ans. Certains préfèreront un moindre
coût souvent, d'autre payer beaucoup mais moins souvent.
Là c'est un peu la même chose : est-ce que l'on préfère passer 2h
chaque semaine pendant un an à retoucher des builds ou est-ce qu'on
préfère se former une semaine à maven, une fois que c'est fait on y
touche plus ? Quelle est la meilleure approche ? Eternel débat :)

Fred

[Olivier Jaquemet]

Et en prenant le risque de s'acheter une paire chaussure à 100 euros pour constater au bout d'une semaine d'utilisation intense qu'elle n'est pas assez souple pour son pied...

2010/4/27 Frédéric Bouquet <bouquet....@gmail.com>

[Frédéric Bouquet]

> Et en prenant le risque de s'acheter une paire chaussure à 100 euros pour
> constater au bout d'une semaine d'utilisation intense qu'elle n'est pas
> assez souple pour son pied...

D'où le travail de veille technologique : fouiller les magasins,
essayer les chaussures, ... google, wikipedia, comparatifs, écouter
les castcodeurs :)

[Guillaume Laforge]

2010/4/27 Arnauld VM <arna...@gmail.com>:
> [...]

> Une autre option découverte récemment serait Gradle (quid du support
> Ivy ?). Quelqu'un a un retour d'expérience sur Gradle ?

Gradle utilise justement Ivy, plutôt que de réinventer inutilement la roue.

--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one

[Arnaud Héritier]

Loupé c'etait l'autre coauteur, aka, Arnaud :-)

Oui Hudson c'est très bien même si il y a de quoi l'améliorer notamment sur le support Maven (-> un autre thread ? :-) ) et que je ne sais pas trop où il va (manque de rigueur à plein de d'égards. Maven me fait déjà froid dans le dos par moment mais Hudson ...)

Donc oui Hudson permet de faire plein de choses comme le réacteur Maven, mais perso je test, j'assemble et déploie avant de commiter d'où l'intérêt de toutes ces options.

Pour les noms des options c'est clair qu'elles sont ridicules mais on à par trouvé mieux. -rf pour resume-from est assez clair, même si il se nous fait penser à nos chères options recursive/force de rm.

Arnaud Héritier
Software Factory Manager
eXo platform - http://www.exoplatform.com
---
http://www.aheritier.net

2010/4/27 Nicolas Delsaux <nicolas...@gmail.com>

[Guillaume Laforge]

C'est clair que l'un des plus gros problèmes de l'informatique, c'est
la communication !
Ce n'est pas les NullPointerException, ou les problème de typages :-)
Et l'autre grand aspect à ne pas oublier, c'est l'aspect "qualité" (à
défaut de trouver un meilleur nom), càd une bonne approche des tests,
etc, pour s'assurer des non-régressions, de la bonne implémentation
des fonctionnalités, etc.

2010/4/27 Jocelyn <lecomt...@free.fr>:

[Olivier Jaquemet]

2010/4/27 Frédéric Bouquet <bouquet....@gmail.com>

> Et en prenant le risque de s'acheter une paire chaussure à 100 euros pour
> constater au bout d'une semaine d'utilisation intense qu'elle n'est pas
> assez souple pour son pied...

D'où le travail de veille technologique : fouiller les magasins,
essayer les chaussures, ... google, wikipedia, comparatifs, écouter
les castcodeurs :)

Je crois que c'est la principale raison pour laquelle nous sommes ici :)

Que ça soit pour participer aux discussion activement ou seulement pour les lire : le groupe compte 163 membres, bcp plus que les 10 principaux rédacteurs... Donc soignez vos paroles messieurs :)

[Antonio Goncalves]

<hibernatus mode='wakeup'>

J'ai la tête dans l'écriture de la 2e édition de mon livre Java EE 6 et lorsque je la lève, que vois-je ? Des tas de mails sur la mailing list des Cast Codeurs.... bon, je vous avouerai, j'ai pas tout lu (surtout la partie sur Maven ;o)

</hibernatus>

2010/4/27 Olivier Jaquemet <olivier....@gmail.com>

--
Antonio Goncalves
Software architect and Java Champion

Web site : www.antoniogoncalves.org
Twitter : twitter.com/agoncal
Blog: agoncal.wordpress.com
LinkedIn: www.linkedin.com/in/agoncal
Paris JUG leader : www.parisjug.org

[Frederic Simon]

A propos de chaussures je confirme:

- J'ai migré des dizaines de clients avec des build complexes vers Maven2! Jusqu'à présent tous les développeurs sont bien contents :) => Succès.

- Maven 2 apporte énormément et l'argument "Mais je veux nommer mes jars comme ça! Mes sources sont dans un répertoire "java"?" m'énerve aussi. Conclusion: J'adopte (et j'enforce) à bras ouvert la plupart des contraintes Maven 2.

- J'ai (pas tout seul :) écrit plusieurs plugins et cycle de vie Maven 2 pour gérer des projets avec EJB, WAR, EAR depuis JEE 4 jusqu'à aujourd'hui JEE 6, avec deployment de EJB3 sur WebSphere 7 utilisant JBoss microcontainer. En un mot: Des plugins de fada, avec des EAR monstrueux :)

Pour moi, le principal obstacle est le fait que Maven 3 résout aucun des problèmes qui me font mal:

- Pas de Mixins (meme si le plein de bouche JVZ l'annonce a qui veux!),

- Donc un arbre multi-projets non flexible (voir le changement dans le code source Wicket entre 1.2 et 1.3),

- La possibilite de re-packager un gros produit en changeant que 2 ou 3 modules,

- La possibilite d'ajouter des cycles de vie sans tuer les développeurs,

- ... 

Ca m'indique un manque d'écoute de la part des créateurs de Maven...

Donc je supportait Maven jusqu'à aujourd'hui, et maintenant: Vive Gradle !

Mais bon, mon mail était destiné aux CC qui donnent la fausse impression que Maven 2, c'est tout beau, c'est facile et ça fait le café!

Mais bon, les réponses prouve que personne n'est dupe :)

2010/4/27 Arnaud Héritier <aher...@gmail.com>

--
http://freddy33.blogspot.com/
http://www.jfrog.org/
http://twitter.com/freddy33

[Antonio Goncalves]

Ha, je viens de me réveiller là :

> Mais bon, mon mail était destiné aux CC qui donnent la fausse impression que Maven 2, c'est tout beau, c'est facile et ça fait le café!

Je n'aime pas Maven (Arnaud peut en témoigner) et je m'attriste tous les jours de constater que l'outils de build le plus répendu dans le monde java est Maven. Ca me désole. Mais bon, entre Maven et Ant, mon choix est fait... en attendant qque chose d'autre qui relève le niveau.

Antonio

2010/4/27 Frederic Simon <frederi...@gmail.com>

--
Antonio Goncalves
Software architect and Java Champion

Web site : www.antoniogoncalves.org
Twitter : twitter.com/agoncal
Blog: agoncal.wordpress.com
LinkedIn: www.linkedin.com/in/agoncal
Paris JUG leader : www.parisjug.org

[Guillaume Laforge]

2010/4/27 Antonio Goncalves <antonio....@gmail.com>:
> [...]

> en attendant qque chose d'autre qui relève le niveau.

<message-subliminal>
Ouvre les yeux, j'arrête pas de t'en parler :-)
</message-subliminal>

--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one

[Antonio Goncalves]

Promis, après mon livre sur Java EE 6, j'écris un livre sur Gradle ;o)

2010/4/27 Guillaume Laforge <glaf...@gmail.com>

--
Antonio Goncalves
Software architect and Java Champion

Web site : www.antoniogoncalves.org
Twitter : twitter.com/agoncal
Blog: agoncal.wordpress.com
LinkedIn: www.linkedin.com/in/agoncal
Paris JUG leader : www.parisjug.org

[Henri Gomez]

On pourra beaucoup critiquer Maven mais il faut lui rendre une
justice, il a permis de construire des repositories de livrable, sur
lesquels les autres se basent maintenant.

Dans la préhistoire Java, on devait aller chercher les jars un peu
partout et les installer à la mano et au feeling dans les IDE, d'abord
et sur les systèmes de production ensuite.

Cela dit avec OSGI et OBR, la donne va probablement encore changer, on
aura besoin non plus d'artifacts mais de bundles, mais ceci est une
autre histoire


Le 27 avril 2010 11:12, Antonio Goncalves
<antonio....@gmail.com> a écrit :

[Nicolas Delsaux]

2010/4/27 Henri Gomez <henri...@gmail.com>:

> On pourra beaucoup critiquer Maven mais il faut lui rendre une
> justice, il a permis de construire des repositories de livrable, sur
> lesquels les autres se basent maintenant.

Oui, à mon sens, c'est l'une des grandes forces de maven : avoir enfin
trouvé une solution pérenne au problème classique des dépendances dans
le gestionnaire de sources (avec aussi le fait d'avoir donné une
organisation typique au code).

>
> Cela dit avec OSGI et OBR, la donne va probablement encore changer, on
> aura besoin non plus d'artifacts mais de bundles, mais ceci est une
> autre histoire
>

En fait, c'est une histoire assez liée : il me semble que certains
serveurs OSGi (je pense par exemple à Apache Karaf) permettent de
transformer à la volée des artefacts maven en bundles OSGi. Bon, c'est
pas forcément très propre comme solution, mais ça assure une
transition douce, non ?

--
Nicolas Delsaux

[Emmanuel Lecharny]

On 4/27/10 11:53 AM, Henri Gomez wrote:
> On pourra beaucoup critiquer Maven mais il faut lui rendre une
> justice, il a permis de construire des repositories de livrable, sur
> lesquels les autres se basent maintenant.
>
> Dans la préhistoire Java, on devait aller chercher les jars un peu
> partout et les installer à la mano et au feeling dans les IDE, d'abord
> et sur les systèmes de production ensuite.
>

Ahhhh, Antonio doit toujours le faire :) J'avoue être assez content de
ne plus avoir à passer par cette étape...

> Cela dit avec OSGI et OBR, la donne va probablement encore changer, on
> aura besoin non plus d'artifacts mais de bundles, mais ceci est une
> autre histoire
>

Alors pour OSGi, j'attend de voir. Peut-être en 2015 ? 2020 ?

--
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com

[Henri Gomez]

>> Dans la préhistoire Java, on devait aller chercher les jars un peu
>> partout et les installer à la mano et au feeling dans les IDE, d'abord
>> et sur les systèmes de production ensuite.
>
> Ahhhh, Antonio doit toujours le faire :) J'avoue être assez content de ne
> plus avoir à passer par cette étape...

Je compatis, sincèrement :)

>> Cela dit avec OSGI et OBR, la donne va probablement encore changer, on
>> aura besoin non plus d'artifacts mais de bundles, mais ceci est une
>> autre histoire
>>
>
> Alors pour OSGi, j'attend de voir. Peut-être en 2015 ? 2020 ?

JVZ va plus vite que ça avec Nexus, bien plus vite

[Antonio Goncalves]

Malheureusement je continue à le faire. C'est impressionnant le nombre de clients qui n'ont pas de repository d'entreprise et  qui ont des proxies qui t'empechent d'aller récupérer les librairies sur le web. Avec du bol j'ai des clients qui commitent leurs jars, et pour d'autres il faut aller à la peche à la librairie sur internet et les rajouter à la mano dans son CP. C'est pour ça que je dis, "Maven, je t'aime, moi non plus".

2010/4/27 Emmanuel Lecharny <elec...@gmail.com>

--
Antonio Goncalves
Software architect and Java Champion

Web site : www.antoniogoncalves.org
Twitter : twitter.com/agoncal
Blog: agoncal.wordpress.com
LinkedIn: www.linkedin.com/in/agoncal
Paris JUG leader : www.parisjug.org

[Clement Escoffier]

Bonjour,

On 27.04.2010, at 11:56, Nicolas Delsaux wrote:

> 2010/4/27 Henri Gomez <henri...@gmail.com>:
>> On pourra beaucoup critiquer Maven mais il faut lui rendre une
>> justice, il a permis de construire des repositories de livrable, sur
>> lesquels les autres se basent maintenant.
>
> Oui, à mon sens, c'est l'une des grandes forces de maven : avoir enfin
> trouvé une solution pérenne au problème classique des dépendances dans
> le gestionnaire de sources (avec aussi le fait d'avoir donné une
> organisation typique au code).
>>
>> Cela dit avec OSGI et OBR, la donne va probablement encore changer, on
>> aura besoin non plus d'artifacts mais de bundles, mais ceci est une
>> autre histoire

JVZ s'est entouré de plusieurs experts OSGi (je pense particulierement a Stuart McCulloch et Pascal Raspicault).
Nexus génère deja les repository OBR et P2.

>>
> En fait, c'est une histoire assez liée : il me semble que certains
> serveurs OSGi (je pense par exemple à Apache Karaf) permettent de
> transformer à la volée des artefacts maven en bundles OSGi. Bon, c'est
> pas forcément très propre comme solution, mais ça assure une
> transition douce, non ?

Le wrapping n'est pas très bon (j'exporte tout, j'importe dynamiquement tout ...), mais fonctione dans beaucoup de cas.
C'est la solution la moins couteuse sur du court terme. Mais sur moyen terme elle est inefficace car un jour ou l'autre il faudrait le faire correctement, et peut etre abstraire la librairie en question via un service. Malheureusement, le service layer d'OSGi est trop souvent oublié ...


Clement

[Henri Gomez]

> JVZ s'est entouré de plusieurs experts OSGi (je pense particulierement a Stuart McCulloch et Pascal Raspicault).
> Nexus génère deja les repository OBR et P2.

JVZ est finalement le seul à pouvoir tenir résister à notre Chuck des CC ?

>> En fait, c'est une histoire assez liée : il me semble que certains
>> serveurs OSGi (je pense par exemple à Apache Karaf) permettent de
>> transformer à la volée des artefacts maven en bundles OSGi. Bon, c'est
>> pas forcément très propre comme solution, mais ça assure une
>> transition douce, non ?
>
> Le wrapping n'est pas très bon (j'exporte tout, j'importe dynamiquement tout ...), mais fonctione dans beaucoup de cas.
> C'est la solution la moins couteuse sur du court terme. Mais sur moyen terme elle est inefficace car un jour ou l'autre il faudrait le faire correctement, et peut etre abstraire la librairie en question via un service. Malheureusement, le service layer d'OSGi est trop souvent oublié ...

Le wrapping automatique n'est pas terrible, si oui, OSGI perd beaucoup
de son intérêt.

[Baptiste MATHUS]

Allez, je me réveille aussi :-).

Le 27 avril 2010 11:03, Frederic Simon <frederi...@gmail.com> a écrit :

Pour moi, le principal obstacle est le fait que Maven 3 résout aucun des problèmes qui me font mal:

- Pas de Mixins (meme si le plein de bouche JVZ l'annonce a qui veux!),

Si je ne m'abuse, les mixins sont prévus pour la 3.1.

 

- La possibilite de re-packager un gros produit en changeant que 2 ou 3 modules,

En quoi les options incrémentales ne répondent pas à ce besoin (-am, -amd, -rf...) ? Peux-tu développer ?

 

- La possibilite d'ajouter des cycles de vie sans tuer les développeurs,

Peut-être, mais tu l'as dit toi même : l'enforcement de règles est aussi très bon pour la structuration. Je ne suis pas sûr de voir la justification à une grande facilité de création de lifecycle. C'est quand même pas tous les jours que c'est nécessaire, si ?

 

Ca m'indique un manque d'écoute de la part des créateurs de Maven...

Je ne fais pas partie de l'équipe de dév, mais franchement je suis plutôt pas d'accord. Maven évolue beaucoup, et vite, mais sans tout péter.

Beaucoup de choses prévues dans la v3 apportent justement des évolutions issues de demandes récurrentes des utilisateurs pendant la v2.

Ce serait intéressant que tu développes ce sujet, parce que si tu as de bonnes idées, et qu'elles ne sont pas ds le tracker, c'est encore le bon moment ;).

 

Donc je supportait Maven jusqu'à aujourd'hui, et maintenant: Vive Gradle !

Mais bon, mon mail était destiné aux CC qui donnent la fausse impression que Maven 2, c'est tout beau, c'est facile et ça fait le café!

Mais bon, les réponses prouvent que personne n'est dupe :)

Disons que les réponses montrent surtout que le débat est là, et c'est une bonne chose. Aucun outil  ne convient à tout le monde. Si on parlait d'appserver, tu en aurais toujours qui chieraient sur JBoss, d'autres sur GF, Websphere, Tomcat, etc. pour diverses raisons.

@++

--
Baptiste <Batmat> MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !

[nicolas de loof]

Le 27 avril 2010 12:28, Henri Gomez <henri...@gmail.com> a écrit :

> JVZ s'est entouré de plusieurs experts OSGi (je pense particulierement a Stuart McCulloch et Pascal Raspicault).
> Nexus génère deja les repository OBR et P2.

Nexus PRO seulement, ce qui veut dire que pour le commun des mortels qui n'arrive pas à débloquer 3cents pour un outil auprès de son service "achat" il n'y a pas encore de solution 

[nicolas de loof]

 

Ca m'indique un manque d'écoute de la part des créateurs de Maven...

Comme dirait l'autre, contributions are welcome !

Pour ma part je ne suis payé pour bosser sur Maven que lorsque cela touche mon boulot pro, et - désolé - mon temps libre est déjà bien assez court.

Certaines fonctionnalités très demandées - je pense au "global exclusion" - ne peuvent être réalisées sans briser la compatibilité ascendante. Sur un outil aussi largement utilisé que Maven on ne peut pas ne pas en tenir compte et demander à tout le monde de mettre à jour leurs builds...

[Arnaud Héritier]

2010/4/27 Baptiste MATHUS <bma...@gmail.com>

Allez, je me réveille aussi :-).

Le 27 avril 2010 11:03, Frederic Simon <frederi...@gmail.com> a écrit :

Pour moi, le principal obstacle est le fait que Maven 3 résout aucun des problèmes qui me font mal:

- Pas de Mixins (meme si le plein de bouche JVZ l'annonce a qui veux!),

Si je ne m'abuse, les mixins sont prévus pour la 3.1.

Jocker. On va dire 3.x. Mais effectivement tout est là pour le gérer. La seule chose qui coince et qui doit être correctement designée c'est la gestion par maven des X versions/formats du descripteur en local et dans les repos distant.

 

 

- La possibilite de re-packager un gros produit en changeant que 2 ou 3 modules,

En quoi les options incrémentales ne répondent pas à ce besoin (-am, -amd, -rf...) ? Peux-tu développer ?

Je pense que le problème cité que je rencontre aussi c'est plutôt le soucis de gérer des variantes de livrables ce qui en théorie pourrait être fait avec des profiles et des classifiers mais aujourd'hui c'est pas correctement géré à mon gout dans Maven (trop complexe, limité ...).

 

 

- La possibilite d'ajouter des cycles de vie sans tuer les développeurs,

Peut-être, mais tu l'as dit toi même : l'enforcement de règles est aussi très bon pour la structuration. Je ne suis pas sûr de voir la justification à une grande facilité de création de lifecycle. C'est quand même pas tous les jours que c'est nécessaire, si ?

Franchement la création de cycle de vie est super rare. Le plus fréquent c'est de ré-ecrire ou compléter ceux par défaut.

 

 

Ca m'indique un manque d'écoute de la part des créateurs de Maven...

Je ne fais pas partie de l'équipe de dév, mais franchement je suis plutôt pas d'accord. Maven évolue beaucoup, et vite, mais sans tout péter.

Beaucoup de choses prévues dans la v3 apportent justement des évolutions issues de demandes récurrentes des utilisateurs pendant la v2.

Ce serait intéressant que tu développes ce sujet, parce que si tu as de bonnes idées, et qu'elles ne sont pas ds le tracker, c'est encore le bon moment ;).

Dire que l'on écoute pas c'est de la connerie. Dire que l'on ne retourne pas notre chemise et suivons nos idées c'est vrai. Après tout ne va pas aussi vite que l'on voudrait car cela demande du temps et les solutions ne sont pas obligatoirement triviales avec les milliers (peut on dire millions ?) d'utilisateurs que nous avons dans le monde.

 

 

Donc je supportait Maven jusqu'à aujourd'hui, et maintenant: Vive Gradle !

Je lui souhaite aussi un bel avenir pour répondre aux 20% de projets tordus qui ne peuvent aller sur les rails de Maven et doivent emprunter les petits chemins dans la montagne. Je leur souhaite surtout d'avoir toujours avec eux un bon guide.

 

Mais bon, mon mail était destiné aux CC qui donnent la fausse impression que Maven 2, c'est tout beau, c'est facile et ça fait le café!

Je ne pense franchement n'avoir jamais dis cela et si c'est ce qui en ressort j'en suis désolé. Si c'était si merveilleux on aurait pas fais les mains dans le cambouis dessus.

 

Mais bon, les réponses prouvent que personne n'est dupe :)

Disons que les réponses montrent surtout que le débat est là, et c'est une bonne chose. Aucun outil  ne convient à tout le monde. Si on parlait d'appserver, tu en aurais toujours qui chieraient sur JBoss, d'autres sur GF, Websphere, Tomcat, etc. pour diverses raisons.

Et puis franchement on s'ennuierai si tout le monde était d'accord.

 

@++

--
Baptiste <Batmat> MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !

--

Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.
Pour envoyer un message à ce groupe, adressez un e-mail à lescast...@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr

[Arnaud Héritier]

 

Ca m'indique un manque d'écoute de la part des créateurs de Maven...

Comme dirait l'autre, contributions are welcome !

Pour ma part je ne suis payé pour bosser sur Maven que lorsque cela touche mon boulot pro, et - désolé - mon temps libre est déjà bien assez court.

Certaines fonctionnalités très demandées - je pense au "global exclusion" - ne peuvent être réalisées sans briser la compatibilité ascendante. Sur un outil aussi largement utilisé que Maven on ne peut pas ne pas en tenir compte et demander à tout le monde de mettre à jour leurs builds...

Ce que peut encore se permettre Gradle aujourd'hui du fait de sa jeunesse (<1.0).

Je ne l'ai pas testé sur du long terme car je n'ai fais que des tests mais je n'ai pas maintenu un build gradle sur plusieurs versions de l'outil. 

C'est cependant ce qu'un développer de l'outil m'a dit. 

Je le crois et je n'y vois rien de mal (au début).

Arnaud

[Baptiste MATHUS]

Le 27 avril 2010 14:22, nicolas de loof <nicolas...@gmail.com> a écrit :

 

Ca m'indique un manque d'écoute de la part des créateurs de Maven...

Comme dirait l'autre, contributions are welcome !

Pour ma part je ne suis payé pour bosser sur Maven que lorsque cela touche mon boulot pro, et - désolé - mon temps libre est déjà bien assez court.

Certaines fonctionnalités très demandées - je pense au "global exclusion" - ne peuvent être réalisées sans briser la compatibilité ascendante. Sur un outil aussi largement utilisé que Maven on ne peut pas ne pas en tenir compte et demander à tout le monde de mettre à jour leurs builds...

 

+1.

Assez souvent, il arrive que les nouvelles idées soient d'ailleurs déjà tracées sur le jira de maven (ou d'un des plugins), soit en train d'attendre des contributions, soit en attente ou bloqué parce qu'une réflexion est en cours pour savoir comment résoudre les problèmes comme la rétro-compatibilité. C'est aussi l'apanage des outils matures que de ne plus pouvoir se permettre autant d'ajouts que les outsiders tellement la base utilisateur est devenue importante et la non régression par la même occasion.

@++

--
Baptiste <Batmat> MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !

[Emmanuel Lecharny]

On 4/27/10 2:16 PM, nicolas de loof wrote:
> Le 27 avril 2010 12:28, Henri Gomez<henri...@gmail.com> a écrit :
>
>
>>> JVZ s'est entouré de plusieurs experts OSGi (je pense particulierement a
>>>
>> Stuart McCulloch et Pascal Raspicault).
>>
>>> Nexus génère deja les repository OBR et P2.
>>>
>>
>>
> Nexus PRO seulement, ce qui veut dire que pour le commun des mortels qui
> n'arrive pas à débloquer 3cents pour un outil auprès de son service "achat"
> il n'y a pas encore de solution
>

Ici, le problème, ce n'est pas Nexus PRO, c'est le service achat. D'un
autre côté, ce genre de boîte va dépenser 10 fois plus en
temps/développeur (et oui, c'est plus facile de payer dix journées d'un
intervenant que d'acheter un produit qui vaut la moitié du prix...).

C'est bien la mentalité française, ça... Vous construisez votre perceuse
quand vous avez besoin de faire un trou chez vous?

--
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com

[Henri Gomez]

> Nexus PRO seulement, ce qui veut dire que pour le commun des mortels qui
> n'arrive pas à débloquer 3cents pour un outil auprès de son service "achat"
> il n'y a pas encore de solution

+1

Par contre, pour ceux qui veulent leur 'logo' sur un Nexus OSS, j'ai
un astuce à 2 cents :)

[nicolas de loof]

je pense qu'on a la même ;)

[Henri Gomez]

> Ici, le problème, ce n'est pas Nexus PRO, c'est le service achat. D'un autre
> côté, ce genre de boîte va dépenser 10 fois plus en temps/développeur (et
> oui, c'est plus facile de payer dix journées d'un intervenant que d'acheter
> un produit qui vaut la moitié du prix...).

Comme j'entends dire souvent (trop souvent), ce n'est pas le même budget.

> C'est bien la mentalité française, ça... Vous construisez votre perceuse
> quand vous avez besoin de faire un trou chez vous?

Non mais la mentalité française, dans les grands comptes a été pendant
très longtemps d'aller chercher des solutions, forts couteuses, chez
des gros éditeurs (genre modèle à 3 lettres).

Comme beaucoup de lobbyeurs, j'ai fait évoluer les mentalités petit à
petit (sur une dizaine d'année quand même) pour retenir des solutions
OpenSource, comme maven, subversion, hudson, sonar.

Avec la crise, ça c'est encore accentué mais attention les vieux
démons ne dorment pas.

Quand tu mets maven puis vend le principe d'un repository
d'entreprise, si tu choisis Nexus OSS, ça passe, si tu annonces Nexus
PRO et son coût, tu prends le risque de voir toute ta stratégie remise
en question.

Et dans ces cas là, c'est Maven, Subversion, Hudson et Nexus qui
pourrait sauter :(

[nicolas de loof]

Ici, le problème, ce n'est pas Nexus PRO, c'est le service achat. D'un autre côté, ce genre de boîte va dépenser 10 fois plus en temps/développeur (et oui, c'est plus facile de payer dix journées d'un intervenant que d'acheter un produit qui vaut la moitié du prix...).

C'est bien la mentalité française, ça... Vous construisez votre perceuse quand vous avez besoin de faire un trou chez vous?

On est bien d'accord, mais manque de pot, on vit en France dans des entreprises Française (au moins pour certains d'entre nous) donc il faut faire avec. Je me coltine un renouvellement tous les mois de la licence Clover "d'évaluation", sachant que la "vraie" licence a été acceptée, mais toujours pas commandée. Sans parler des licences pour Yourkit, alors qu'on baigne dans les fuites mémoire. Et encore, ce sont des outils sur projet, donc pour lesquels il y a un budget, mais pour des outils communs, pas un kopek.

C'est sans doute un mal franco-français, qui ne trouve que de mauvaises solutions

 

--
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com


--

Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.
Pour envoyer un message à ce groupe, adressez un e-mail à lescast...@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr

[Henri Gomez]

mod_jk ou mod_proxy ?

Pour ma part :

AccessFileName .htaccess
JkMount /nexus/* nexus
SetEnvIf Request_URI "/nexus/images/branding.png" no-jk

:)

[Henri Gomez]

> On est bien d'accord, mais manque de pot, on vit en France dans des
> entreprises Française (au moins pour certains d'entre nous) donc il faut
> faire avec. Je me coltine un renouvellement tous les mois de la licence
> Clover "d'évaluation", sachant que la "vraie" licence a été acceptée, mais
> toujours pas commandée. Sans parler des licences pour Yourkit, alors qu'on
> baigne dans les fuites mémoire. Et encore, ce sont des outils sur projet,
> donc pour lesquels il y a un budget, mais pour des outils communs, pas un
> kopek.
> C'est sans doute un mal franco-français, qui ne trouve que de mauvaises
> solutions

<tristeconstat>
Le mal français, c'est surtout que le technique, l'implémentation, le
code, c'est sale.
L'aspect noble, c'est le fonctionnel et le métier.
</tristeconstat>

[nicolas de loof]

écrasement pur et simple du png "nexus"

[Emmanuel Lecharny]

On 4/27/10 2:57 PM, Henri Gomez wrote:
>> On est bien d'accord, mais manque de pot, on vit en France dans des
>> entreprises Française (au moins pour certains d'entre nous) donc il faut
>> faire avec. Je me coltine un renouvellement tous les mois de la licence
>> Clover "d'évaluation", sachant que la "vraie" licence a été acceptée, mais
>> toujours pas commandée. Sans parler des licences pour Yourkit, alors qu'on
>> baigne dans les fuites mémoire. Et encore, ce sont des outils sur projet,
>> donc pour lesquels il y a un budget, mais pour des outils communs, pas un
>> kopek.
>> C'est sans doute un mal franco-français, qui ne trouve que de mauvaises
>> solutions
>>
> <tristeconstat>
> Le mal français, c'est surtout que le technique, l'implémentation, le
> code, c'est sale.
> L'aspect noble, c'est le fonctionnel et le métier.
> </tristeconstat>
>

Et oui... Si a 50 ans t'as pas de Rolex, t'as raté ta vie, mais en
France, si à 30 ans tu n'es pas chef de projet, tu n'est qu'une merde
sèche sur le coin d'une rue qui sent la pisse...

Bon, d'un autre côté, c'est bien, quand il y a un problème technique (et
ça ne manque pas d'arriver sur les projects foireux où il y a plus de
chefs de projets que de développeurs expérimentés), les vieux qui aiment
bien coder se font des bonbons en or en venant nettoyer les écuries
d'augias. Comme quoi, tout problème engendre son écosysème ;)

<Anecdote>
Ca me rappelle le gars que j'avais rencontré un soir il y a qq années
qui a 45 ans se vendait à 15 000 frs (2500€) la journée, (50 jours par
an, le reste, il était en vacances) pour patcher du code sur PDP-11(
http://fr.wikipedia.org/wiki/PDP-11). En 2005, qui utilisait encore des
PDP-11 ? Il avait 4 clients en France, des entreprises d'édition qui
utilisaient des photocomposeuses contenant un PDP-11. Et il n'avait pas
beaucoup de concurrence, d'où ses tarifs ;)

D'après lui, il pouvait tenir encore une petite dizaine d'année avant de
prendre sa retraite...
</Anecdote>

--
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com

[nicolas de loof]

<Anecdote>
Ca me rappelle le gars que j'avais rencontré un soir il y a qq années qui a 45 ans se vendait à 15 000 frs (2500€) la journée, (50 jours par an, le reste, il était en vacances) pour patcher du code sur PDP-11( http://fr.wikipedia.org/wiki/PDP-11). En 2005, qui utilisait encore des PDP-11 ? Il avait 4 clients en France, des entreprises d'édition qui utilisaient des photocomposeuses contenant un PDP-11. Et il n'avait pas beaucoup de concurrence, d'où ses tarifs ;)

D'après lui, il pouvait tenir encore une petite dizaine d'année avant de prendre sa retraite...
</Anecdote>

Cool, ça me fait un bon plan de fin de carrière à maintenir les builds Maven après 2040 ;) 

[Marc Guillemot]

nicolas de loof wrote:
> ...

>
> C'est sans doute un mal franco-français, qui ne trouve que de mauvaises
> solutions

je ne pense pas que ce soit un problème franco-français. J'ai vu les
mêmes problèmes en Suisse et en Allemagne.

Marc.

[Frederic Simon]

Ca c'est bien du Sonatype Nexus :)

Avec Artifactory OSS il y a une jolie page Web d'administration ou on peut faire ca normalement!
http://wiki.jfrog.org/confluence/display/RTF/General+Configuration

A propos de changer 2 ou 3 modules dans un produit, je parle du problème de parent dynamique...

J'ai un client avec + de 400 modules reparti sur 8 gros multi-modules.

L'un des gros machin c'est bien sur le core framework qui contient 68 modules. Ben a chaque fois qu'il faut sortir une nouvelle version (patch) pour 2 modules modifies: Changement complet de la version, et redeployment complet des 68 modules...

Ca fait mal!

Et croyait moi j'ai peser le pour et le contre de toutes les options.

Voila, on migre doucement vers Gradle et tout va bien :)

2010/4/27 Henri Gomez <henri...@gmail.com>

--
http://freddy33.blogspot.com/
http://www.jfrog.org/
http://twitter.com/freddy33

[Arnaud Héritier]

400 modules ? pfff. C'est un projet avec 2000 développeurs en // ?

2010/4/27 Frederic Simon <frederi...@gmail.com>

[Emmanuel Lecharny]

On 4/27/10 4:01 PM, Arnaud Héritier wrote:
> 400 modules ? pfff. C'est un projet avec 2000 développeurs en // ?
>

moi, ce qui m'amuse c'est l'obligation de releaser tout pour deux
pauvres modules qui changent. Ca sent son couplage fort, je pense pas
que gradle apporte une solution...

Enfin, on s'amuse comme on peut...

--
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com

[Arnaud Héritier]

C'est vrai que Maven n'aide pas.

Si tu as vraiment besoin de XX modules/projets tu n'as que deux solutions :

- Soit tout le monde est aligné sur la même version et donc tu releases tout même si tu n'en as changé qu'une petite partie.

- Soit les projets/modules sont indépendants. Ils ont leur propre cycle de vie. Un reactor n'est souvent plus utile car les dépendances sont des releases et non pas des SNAPSHOTs. Tu ne releases que ce que tu as besoin mais un par un, il faut t'amuser à gérer les impacts sur les changements de version et trouver qui t'utilise pour les mettre à jour (genre tu dois faire la release de l'ear qui contient une nouvelle version du jar).

Bref dans ce deuxième cas avec Maven ça va pas être simple mais je ne pense pas que cela le soit plus avec un autre produit.

2010/4/27 Emmanuel Lecharny <elec...@gmail.com>

[Emmanuel Lecharny]

On 4/27/10 4:20 PM, Arnaud Héritier wrote:
> C'est vrai que Maven n'aide pas.
> Si tu as vraiment besoin de XX modules/projets tu n'as que deux solutions :
> - Soit tout le monde est aligné sur la même version et donc tu releases tout
> même si tu n'en as changé qu'une petite partie.
> - Soit les projets/modules sont indépendants. Ils ont leur propre cycle de
> vie. Un reactor n'est souvent plus utile car les dépendances sont des
> releases et non pas des SNAPSHOTs. Tu ne releases que ce que tu as besoin
> mais un par un, il faut t'amuser à gérer les impacts sur les changements de
> version et trouver qui t'utilise pour les mettre à jour (genre tu dois faire
> la release de l'ear qui contient une nouvelle version du jar).
> Bref dans ce deuxième cas avec Maven ça va pas être simple mais je ne pense
> pas que cela le soit plus avec un autre produit.
>

En ce qui me concerne, avec mes 7 projets et mes 65 modules répartis
parmi ces 7 projects, quand je release un des projets, généralement, il
ne me faut que quelques minutes pour mettre à jour les dépendances
(merci le dependencyManager).

Pour moi, ce n'est pas un problème produit, c'est un problème
d'organisation. Je ne pense pas que Graddle apporte une solution dans ce
cadre. Quand je lis ce qui est écrit sur le site de Gradle :
" We don't believe in tools that save people from themselves. Gradle
gives you all the freedom you need..."
je me dis qu'un outil qui te laisse t'arracher une jambe, c'est super.
Perso, j'aime bien que Maven me contraigne, cela me protège contre
moi-même. J'ai un peu autre chose à foutre qu'à réimaginer ce qui a été
pondu par qq dizaines de personnes, qui est utilisé par des centaines de
milliers de par le monde, avec succès.

Maintenant, chacun perd son temps comme il le veut...

PS : bien sûr, cela n'engage que moi. Si je me trompe, que je soit
réincarné en coprophage...

[Guillaume Laforge]

2010/4/27 Emmanuel Lecharny <elec...@gmail.com>:
> [...]

> Pour moi, ce n'est pas un problème produit, c'est un problème
> d'organisation. Je ne pense pas que Graddle apporte une solution dans ce
> cadre. Quand je lis ce qui est écrit sur le site de Gradle :
> " We don't believe in tools that save people from themselves. Gradle gives
> you all the freedom you need..."
> je me dis qu'un outil qui te laisse t'arracher une jambe, c'est super.
> Perso, j'aime bien que Maven me contraigne, cela me protège contre moi-même.
> J'ai un peu autre chose à foutre qu'à réimaginer ce qui a été pondu par qq
> dizaines de personnes, qui est utilisé par des centaines de milliers de par
> le monde, avec succès.

Ca se voit que t'as pas bien regardé plus loin que le bout de ton nez là !
C'est pas parce que tu as plus de flexibilité et plus de liberté que
ton build va partir en couille.

> Maintenant, chacun perd son temps comme il le veut...
>
> PS : bien sûr, cela n'engage que moi. Si je me trompe, que je soit réincarné
> en coprophage...

Ah ben maintenant je comprends mieux.
Je me disais que je t'avais déjà vu quelque part :-)

--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one

[Arnaud Héritier]

2010/4/27 Guillaume Laforge <glaf...@gmail.com>

2010/4/27 Emmanuel Lecharny <elec...@gmail.com>:
> [...]

> Pour moi, ce n'est pas un problème produit, c'est un problème
> d'organisation. Je ne pense pas que Graddle apporte une solution dans ce
> cadre. Quand je lis ce qui est écrit sur le site de Gradle :
> " We don't believe in tools that save people from themselves. Gradle gives
> you all the freedom you need..."
> je me dis qu'un outil qui te laisse t'arracher une jambe, c'est super.
> Perso, j'aime bien que Maven me contraigne, cela me protège contre moi-même.
> J'ai un peu autre chose à foutre qu'à réimaginer ce qui a été pondu par qq
> dizaines de personnes, qui est utilisé par des centaines de milliers de par
> le monde, avec succès.

Ca se voit que t'as pas bien regardé plus loin que le bout de ton nez là !
C'est pas parce que tu as plus de flexibilité et plus de liberté que
ton build va partir en couille.

+100

C'est parceque tu as des gens qui y pige rien et qui vont faire n'importe quoi avec. L'avantage c'est qu'avec Maven il y a des rails et ça retient un peu les conneries (c'est pas tout le monde qui crée son plugin en 5min). Avec un outil de script, c'est tellement facile que ca devient vite ingérable.

Une fois de plus le problème n'est pas l'outil mais bien les personnes qui sont derrières. Que ça soit Gradle, Maven ou BuildR (quoique . ;-) ) si ceux qui mettent en place sont de bons architectes et connaissent très bien leurs outils c'est le succès assuré. Le problème c'est qu'on a pas souvent cela dans les équipes projets puisque nos développeurs sont des juniors (à 30ans ils sont CDP - cf autre thread) et que pour beaucoup cela n'est pas une vocation (ils n'iront pas lire la doc Gradle aussi riche soit-elle en anglais). 

(Le serpent se mort la .... J'arrete)

[Frédéric Bouquet]

> Une fois de plus le problème n'est pas l'outil mais bien les personnes qui
> sont derrières. Que ça soit Gradle, Maven ou BuildR (quoique . ;-) ) si ceux
> qui mettent en place sont de bons architectes et connaissent très bien leurs
> outils c'est le succès assuré. Le problème c'est qu'on a pas souvent cela
> dans les équipes projets puisque nos développeurs sont des juniors (à 30ans
> ils sont CDP - cf autre thread) et que pour beaucoup cela n'est pas une
> vocation (ils n'iront pas lire la doc Gradle aussi riche soit-elle en
> anglais).
> (Le serpent se mort la .... J'arrete)

Merci Arnaud pour ce résumé précis et concis des deux derniers jours
de débats sur la liste des cast codeurs. S'il y a une chose à retenir,
c'est bien ça :
- Problème de compétence et/ou d'intérêt
- Folie des chefs de projets et mauvaise réputation des développeurs
- L'anglophobie

Fred

[Henri Gomez]

> Merci Arnaud pour ce résumé précis et concis des deux derniers jours
> de débats sur la liste des cast codeurs. S'il y a une chose à retenir,
> c'est bien ça :
> - Problème de compétence et/ou d'intérêt
> - Folie des chefs de projets et mauvaise réputation des développeurs
> - L'anglophobie

N'oublions pas le syndrome, NIH (Not Invented Here), qui au contraire
créer une sur productivité créative de certaines personnes pensant
bien faire.

[Emmanuel Lecharny]

On 4/27/10 4:55 PM, Guillaume Laforge wrote:
> 2010/4/27 Emmanuel Lecharny<elec...@gmail.com>:
>
>> [...]
>> Pour moi, ce n'est pas un problème produit, c'est un problème
>> d'organisation. Je ne pense pas que Graddle apporte une solution dans ce
>> cadre. Quand je lis ce qui est écrit sur le site de Gradle :
>> " We don't believe in tools that save people from themselves. Gradle gives
>> you all the freedom you need..."
>> je me dis qu'un outil qui te laisse t'arracher une jambe, c'est super.
>> Perso, j'aime bien que Maven me contraigne, cela me protège contre moi-même.
>> J'ai un peu autre chose à foutre qu'à réimaginer ce qui a été pondu par qq
>> dizaines de personnes, qui est utilisé par des centaines de milliers de par
>> le monde, avec succès.
>>
> Ca se voit que t'as pas bien regardé plus loin que le bout de ton nez là !
> C'est pas parce que tu as plus de flexibilité et plus de liberté que
> ton build va partir en couille.
>

J'ai pas dit : "plus de flexibilité => partage en couille", j'ai dit
"Plus de flexibilité => plus de risque que ça se termine en paté de
couille...". Et là, tu auras du mal à dire le contraire :)

--
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com

[Guillaume Laforge]

2010/4/27 Henri Gomez <henri...@gmail.com>:

>> Merci Arnaud pour ce résumé précis et concis des deux derniers jours
>> de débats sur la liste des cast codeurs. S'il y a une chose à retenir,
>> c'est bien ça :
>> - Problème de compétence et/ou d'intérêt
>> - Folie des chefs de projets et mauvaise réputation des développeurs
>> - L'anglophobie
>
> N'oublions pas le syndrome, NIH (Not Invented Here), qui au contraire
> créer une sur productivité créative de certaines personnes pensant
> bien faire.

Et puis on oublie aussi la résistance au changement.
On souffre avec un build de merde à maintenir, au lieu d'investir le
minimum de temps pour voir si une meilleure solution existe.

--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one

[Guillaume Laforge]

2010/4/27 Emmanuel Lecharny <elec...@gmail.com>:
> [...]

> J'ai pas dit : "plus de flexibilité => partage en couille", j'ai dit "Plus
> de flexibilité => plus de risque que ça se termine en paté de couille...".
> Et là, tu auras du mal à dire le contraire :)

Ouais, mais c'est là qu'on dit verge... euh diverge, pardon.
Oui, il y a certainement plus de risque, mais je suis pas trop du
genre ceinture et bretelle ou sarko-maso, j'aime bien donner de la
liberté au gens.
Après, qu'ils prennent leurs responsabilités s'ils font n'importe
quoi, mais je vais pas les frustrer et les engoncer dans une boîte
sous prétexte qu'ils pourraient plus facilement faire n'importe quoi.
Faut savoir aussi faire confiance aux gens.

--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one

[Emmanuel Lecharny]

On 4/27/10 5:22 PM, Guillaume Laforge wrote:
> 2010/4/27 Henri Gomez<henri...@gmail.com>:
>
>>> Merci Arnaud pour ce résumé précis et concis des deux derniers jours
>>> de débats sur la liste des cast codeurs. S'il y a une chose à retenir,
>>> c'est bien ça :
>>> - Problème de compétence et/ou d'intérêt
>>> - Folie des chefs de projets et mauvaise réputation des développeurs
>>> - L'anglophobie
>>>
>> N'oublions pas le syndrome, NIH (Not Invented Here), qui au contraire
>> créer une sur productivité créative de certaines personnes pensant
>> bien faire.
>>
> Et puis on oublie aussi la résistance au changement.
> On souffre avec un build de merde à maintenir, au lieu d'investir le
> minimum de temps pour voir si une meilleure solution existe.
>

Faut pas oublier aussi le syndrome de la star : un/e mec/nana super
brillant qui a 3 idées par minutes, qui pousse sa solution sur un
projet, et comme c'est une star, personne ne moufte. Puis trois mois
après, il se casse faire la star sur un autre projet, et personne ne
comprend rien à ce qu'il a fait, car en fait, c'est la seule star du
projet, et les autres ce sont juste des grouillots à peine bon à aligner
deux setters en Java, ou alors des chefs de projets ratés (en fait, des
développeurs de plus de 27 ans).

Plantage assuré aussi !

La veille technologique, ce n'est pas dans le cadre d'un projet que tu
la fais, Guillaume.

--
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com

[Emmanuel Lecharny]

On 4/27/10 5:25 PM, Guillaume Laforge wrote:
> 2010/4/27 Emmanuel Lecharny<elec...@gmail.com>:
>
>> [...]
>> J'ai pas dit : "plus de flexibilité => partage en couille", j'ai dit "Plus
>> de flexibilité => plus de risque que ça se termine en paté de couille...".
>> Et là, tu auras du mal à dire le contraire :)
>>
> Ouais, mais c'est là qu'on dit verge... euh diverge, pardon.
> Oui, il y a certainement plus de risque, mais je suis pas trop du
> genre ceinture et bretelle ou sarko-maso, j'aime bien donner de la
> liberté au gens.
>

J'aime bien la liberté aussi. Mais à condition qu'on me donne le
budget/temps adéquat.

> Après, qu'ils prennent leurs responsabilités s'ils font n'importe
> quoi, mais je vais pas les frustrer et les engoncer dans une boîte
> sous prétexte qu'ils pourraient plus facilement faire n'importe quoi.
> Faut savoir aussi faire confiance aux gens.
>

Déjà que je ne me fait pas confiance pour pondre autre chose que de
l'engrais pour rosier, alors...

Sérieusement, une part de liberté, ok, mais sur le Build, honnêtement,
zéro liberté. Faut que ça marche, ne prenne pas plus de qq jours à
installer, et pi c'est tout.

Bien sûr, je parle de projet en entreprise avec coût limité, temps
réduit et compétences restreintes. Un VRAI projet, quoi :)

--
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com

[Frederic Simon]

Mais c'est exactement le point fallacieux (pour Guillaume pas de reference phal..que)!

Avec Maven c'est pas comme ca! Coût nul, tout benef, pas de problèmes et ça roule pendant des années sans rien toucher!

C'est pas de l'intelligence artificielle le Maven quoi! Arrêtez de promulguer de la fausse information.

2010/4/27 Emmanuel Lecharny <elec...@gmail.com>

--
http://freddy33.blogspot.com/
http://www.jfrog.org/
http://twitter.com/freddy33

[Guillaume Laforge]

Sur le "ça roule pendant des années sans rien toucher", ça me rappelle
un tout petit projet, tout simple, tout bête, qui sortait pas des
sentiers battus, que j'avais fait avec amour avec Maven 2... je le
resors du placard un an plus tard... et bizarrement le build marchait
plus.
C'était une histoire de plugin, de mauvaise version, je ne sais quoi... super...

2010/4/27 Frederic Simon <frederi...@gmail.com>:

--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one

[Emmanuel Lecharny]

On 4/27/10 6:54 PM, Guillaume Laforge wrote:
> Sur le "ça roule pendant des années sans rien toucher", ça me rappelle
> un tout petit projet, tout simple, tout bête, qui sortait pas des
> sentiers battus, que j'avais fait avec amour avec Maven 2... je le
> resors du placard un an plus tard... et bizarrement le build marchait
> plus.
> C'était une histoire de plugin, de mauvaise version, je ne sais quoi... super...
>

Tu devais utiliser des SNAPSHOTS ou pire, tu avais oublié de définir les
versions des jars et plugins à utiliser ...
tss tss tss

Moi je dis, ç ava se finir en bière tout ces threads, ça donne hyper soif !

[Julien Viet]

faire un build maven sans définir explictement les versions de chaque
plugin utilisé c est la roulette russe.

[Clement Escoffier]

On 27.04.2010, at 19:12, Julien Viet wrote:

> faire un build maven sans définir explictement les versions de chaque plugin utilisé c est la roulette russe.

D'ailleurs il semblerais que cette regle soit 'enforcé' and maven 3.


Clement