[LCC] Découpage des responsabilités : différents projets maven ou différents packages?

[Jean-Sébastien FRANCK]

Bonjour à tous,

Je suis confronté à une problématique de conception et j'hésite entre deux solutions possibles. Contexte : Une couche de traitement métier doit accéder à plusieurs repositories distincts : un repository qui tape sur une base de données via hibernate, un repository qui tape sur des WS maison et un repository qui tape sur des WS google. Chacun de ses repository ont des dépendances bien à eux : notamment hibernate et l'api google.

Pour séparer ma couche métier et mes 3 repository, j'hésite à faire 4 projets maven ou alors à utiliser le packaging java, c'est à dire chaque couche à son propre packaging.

Les avantages que je vois à partir sur 4 projets maven et que les dépendances qu'utilisent chaque repository ne seront pas visibles par les autres repositories (par exemple je n'aurai pas accès aux packages javax.persistence à partir de mon repository WS). De plus, si jamais j'ai le besoin de réutiliser un de mes repositories dans un autre projet, j'aurais déjà un .jar tout fait réutilisable, mais je réfute un peu ce dernier argument car c'est YAGNI.

L'avantage d'utiliser le packaging java est de ne pas s’embêter avec plusieurs projets maven (ok je suis un dév et je suis par nature fainéant). Le coût de faire plusieurs projets maven en vaut-il vraiment la peine? N'est-ce pas se compliquer la vie pour pas grand chose? Utiliser les package java et la visibilité par défaut ne suffit-elle pas?

D'une manière générale, j'aimerai donc savoir si vous pensez qu'un découpage par packaging suffit ou si d'une manière générale plus on fait de jar mieux on se porte.

Merci d'avance pour vos lumières.

[Nicolas Delsaux]

2012/6/13 Jean-Sébastien FRANCK <jsebf...@gmail.com>:

> Bonjour à tous,
>
> Je suis confronté à une problématique de conception et j'hésite entre deux
> solutions possibles. Contexte : Une couche de traitement métier doit accéder
> à plusieurs repositories distincts : un repository qui tape sur une base de
> données via hibernate, un repository qui tape sur des WS maison et un
> repository qui tape sur des WS google. Chacun de ses repository ont des
> dépendances bien à eux : notamment hibernate et l'api google.

J'imagine que ces repositories présentent la même interface, non ?

>
> Pour séparer ma couche métier et mes 3 repository, j'hésite à faire 4
> projets maven ou alors à utiliser le packaging java, c'est à dire chaque
> couche à son propre packaging.

Jamais entendu parler des modules maven ?
Parce que ça correspond *exactement* à ce genre de cas d'utilisation.
Et c'est utilisé par exemple quand tu fais une application web : le
front-end web (dans un war) est développé dans un module, le back-end
(ejb-jar) dans un autre module, et un troisième module se charge de
packager l'ear qui contient tout ça.

La première fois que tu le fais, ça fait un peu usine à gaz, mais on
s'y habitue *très* vite, je trouve.

--
Nicolas Delsaux

[Moandji Ezana]

Je ne pense pas qu'il soit nécessaire de faire ce choix dès le début. Si le plus facile c'est de tout mettre dans le même projet, autant faire comme ça, mais en faisant attention à éviter les dépendences entre repositories. Par la suite, il sera relativement aisé de séparer en plusieurs projets Maven si le besoin survient.

Je n'ai jamais compris l'utilité des modules. Dans ce cas-ci, pourquoi ne pas simplement publier les artifacts normalement dans un repo d'entreprise? Surtout si c'est dans un objectif de réutilisation par d'autres projets.

Moandji

2012/6/13 Nicolas Delsaux <nicolas...@gmail.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

[Jeff MAURY]

Je conseillerais de séparer en plusieurs modules Maven: ca te permet par exemple de lancer un build sur un des modules et pas sur l'ensemble, utile quand tu commences à avoir une batterie de tests conséquentes.
Et cela représente mieux la séparation contrat / implémentation

Jeff

2012/6/13 Nicolas Delsaux <nicolas...@gmail.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

--
Jeff MAURY


"Legacy code" often differs from its suggested alternative by actually working and scaling.
 - Bjarne Stroustrup

http://www.jeffmaury.com
http://riadiscuss.jeffmaury.com
http://www.twitter.com/jeffmaury

[Emmanuel Lécharny]

Le 6/13/12 3:25 PM, Moandji Ezana a écrit :

> Je ne pense pas qu'il soit nécessaire de faire ce choix dès le début. Si le
> plus facile c'est de tout mettre dans le même projet, autant faire comme
> ça,

Pouah !!!

> mais en faisant attention à éviter les dépendences entre repositories.
> Par la suite, il sera relativement aisé de séparer en plusieurs projets
> Maven si le besoin survient.

Autant le faire dès le début, si ça correspond à un besoin...

Et OSGi ? (bon, ok, je sors...)

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

[ehsavoie]

Il te faut un module qui correspond à une partie util / common / support
Ensuite il est preferrable de séparer selon le metier plutot que selon
l'aspect technique
Après la répartition en jars, sous projets maven, packages, bundle
osgi et packages java 8 c'est à toi de voir
----------
Emmanuel Hugonnet
http://www.ehsavoie.com
http://twitter.com/ehsavoie


2012/6/13 Emmanuel Lécharny <elec...@gmail.com>:

[Laurent Forêt]

Ca sert à ça un module maven : à découpler !  Ne pas l'utiliser c'est manqué un des intérêts de maven. 

Donc un Module contenant l'api/spi , un module par implémentation au nombre de 2 et un module client. Quatre , le compte est bon .

Si vous changer d'implémentation vous pouvez toujours jeter le module qui va plus et par la même toutes ces dépendances. Ca a du bon la transitivité.

Laurent Forêt
http://www.devcoop.fr

2012/6/13 ehsavoie <emmanuel...@gmail.com>

[Baptiste MATHUS]

+1.

Projet multi-modules Maven.

Baptiste

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

[Moandji Ezana]

2012/6/13 Emmanuel Lécharny <elec...@gmail.com>

Autant le faire dès le début, si ça correspond à un besoin...

C'est bien ce que j'ai dit. Jean-Sébastien ne sait pas encore si c'est nécessaire. Vu que le coût d'extraire ces packages en artifacts Maven indépedents par la suite est très faible, pourquoi le faire maintenant si le bénéfice est inconnu?

Pour les fans des modules: j'en ai peut-être une mauvaise compréhension, mais les modules ne sont-ils pas faits pour des éléments d'un *même* projet? Or, ici, l'intérêt d'avoir des artifacts séparés, c'est de les utiliser dans plusieurs projets.

Moandji

[Emmanuel Lécharny]

Le 6/13/12 5:08 PM, Moandji Ezana a écrit :

> 2012/6/13 Emmanuel Lécharny<elec...@gmail.com>
>
>> Autant le faire dès le début, si ça correspond à un besoin...
>>
> C'est bien ce que j'ai dit. Jean-Sébastien ne sait pas encore si c'est
> nécessaire.

En fait, ce que j'ai voulu dire, c'est qu'il semble que cela corresponde
à un besoin, donc il faut le faire. C'est un peu comme se demander s'il
faut créer une interface ou pas, le mieux est de le faire tout de suite,
ça ne mange pas de pain.

> Vu que le coût d'extraire ces packages en artifacts Maven
> indépedents par la suite est très faible, pourquoi le faire maintenant si
> le bénéfice est inconnu?

Dès que la question se pose, c'est qu'il y a un besoin. Découpler plus
tard, c'est juste carrément plus pénible.

>
> Pour les fans des modules: j'en ai peut-être une mauvaise compréhension,
> mais les modules ne sont-ils pas faits pour des éléments d'un *même*
> projet? Or, ici, l'intérêt d'avoir des artifacts séparés, c'est de les
> utiliser dans plusieurs projets.

Chaque module est complètement indépendant. Il peut être utilisé par
d'autre projet, si besoin, puisqu'il va faire l'objet d'un artifact qui
sera présent dans ton repo, si tu le déploies, bien sûr.

En fait, la bonne question est plutôt de savoir ce que tu déploies dans
le repo central pour que ce soit visible. Mais rien ne t'empêche de
découper en modules avant.

C'est un peu comme se demander si on met toutes les classes dans un même
package, ou si on créer des packages distincts.

[Baptiste MATHUS]

Là tu auras bien les deux : la séparation claire des dépendances et l'impossibilité de créer des liens pourraves (genre circulaires entre l'UI et ta couche métier, tout à fait possible dans un seul projet, et ce n'est pas un exemple en l'air).

Et côté dépendances, d'un point de vue externe, rien ne différencie un "module" Maven d'un projet classique (et en fait, même en interne, c'est pratiquement pareil). Le jar produit aura strictement la même forme et sera utilisable pareil que s'il avait été produit via un projet autonome.

-- 

[Laurent Forêt]

2012/6/13 Emmanuel Lécharny <elec...@gmail.com>

Le 6/13/12 5:08 PM, Moandji Ezana a écrit :

2012/6/13 Emmanuel Lécharny<elec...@gmail.com>

Autant le faire dès le début, si ça correspond à un besoin...

C'est bien ce que j'ai dit. Jean-Sébastien ne sait pas encore si c'est
nécessaire.

En fait, ce que j'ai voulu dire, c'est qu'il semble que cela corresponde à un besoin, donc il faut le faire. C'est un peu comme se demander s'il faut créer une interface ou pas, le mieux est de le faire tout de suite, ça ne mange pas de pain.

Vu que le coût d'extraire ces packages en artifacts Maven
indépedents par la suite est très faible, pourquoi le faire maintenant si
le bénéfice est inconnu?

Dès que la question se pose, c'est qu'il y a un besoin. Découpler plus tard, c'est juste carrément plus pénible.

Pour les fans des modules: j'en ai peut-être une mauvaise compréhension,
mais les modules ne sont-ils pas faits pour des éléments d'un *même*
projet? Or, ici, l'intérêt d'avoir des artifacts séparés, c'est de les
utiliser dans plusieurs projets.

Chaque module est complètement indépendant. Il peut être utilisé par d'autre projet, si besoin, puisqu'il va faire l'objet d'un artifact qui sera présent dans ton repo, si tu le déploies, bien sûr.

+1. Il suffit de prendre l'exemple de CXF, c'est celui que je connais le mieux. Ils sont partis du principe: je ne veux pas présager de ce que tu vas faire de mes modules, et je vais les découper de telle manière à ce que tu prennes ce qu'il t'interesse. Mais ils sont partis du principe aussi qu'ils voulaient en interne découpler leur code en isolant les différents modules. 

Deux raisons différentes mais qui amène au  même résultat. 

C'est pourquoi dans cxf tu as des modules : 

cxf-rt-transports-jms si tu veux utiliser pour couche de transport JMS

cxf-rt-transports-http si tu veux utiliser pour couche de transport HTTP

PAreil pour la partie frontent je fais du jaxrs ou du jaxws. 

  

 

En fait, la bonne question est plutôt de savoir ce que tu déploies dans le repo central pour que ce soit visible. Mais rien ne t'empêche de découper en modules avant.

C'est un peu comme se demander si on met toutes les classes dans un même package, ou si on créer des packages distincts.

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

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.

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

[Laurent Forêt]

2012/6/13 Baptiste MATHUS <bma...@batmat.net>

Le 13 juin 2012 17:08, Moandji Ezana <mwa...@gmail.com> a écrit :

2012/6/13 Emmanuel Lécharny <elec...@gmail.com>

Autant le faire dès le début, si ça correspond à un besoin...

C'est bien ce que j'ai dit. Jean-Sébastien ne sait pas encore si c'est nécessaire. Vu que le coût d'extraire ces packages en artifacts Maven indépedents par la suite est très faible, pourquoi le faire maintenant si le bénéfice est inconnu?

Pour les fans des modules: j'en ai peut-être une mauvaise compréhension, mais les modules ne sont-ils pas faits pour des éléments d'un *même* projet? Or, ici, l'intérêt d'avoir des artifacts séparés, c'est de les utiliser dans plusieurs projets.

Là tu auras bien les deux : la séparation claire des dépendances et l'impossibilité de créer des liens pourraves (genre circulaires entre l'UI et ta couche métier, tout à fait possible dans un seul projet, et ce n'est pas un exemple en l'air).

M'en parle pas je suis en plein dedans ;) ! 

Je pars d'un projet monolitique sur ant struts vers un projet multi-module maven exposant ces services via des Webservices et ejb3. 

Comme quoi d'un projet en régie vendu (et là je mélange des threads) comme étant maintenance applicative d'une application jdbc/ struts1.0 on peut en faire quelque chose et être moteur de quelque chose.

 

Et côté dépendances, d'un point de vue externe, rien ne différencie un "module" Maven d'un projet classique (et en fait, même en interne, c'est pratiquement pareil). Le jar produit aura strictement la même forme et sera utilisable pareil que s'il avait été produit via un projet autonome.

+1.

 

-- 

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

--

[Moandji Ezana]

2012/6/13 Baptiste MATHUS <bma...@batmat.net>

Et côté dépendances, d'un point de vue externe, rien ne différencie un "module" Maven d'un projet classique (et en fait, même en interne, c'est pratiquement pareil). Le jar produit aura strictement la même forme et sera utilisable pareil que s'il avait été produit via un projet autonome.

D'après "Maven: The Complete Reference" : "When setting up a multimodule project, you are simply telling a project that its build should include the specified modules. Multimodule builds are to be used to group modules together in a single build."

Pourquoi builder les clients des repositories en même temps que le reste du projet? Clairement, les cycles de vie sont différents.

Emmanuel Lécharny:

C'est un peu comme se demander s'il faut créer une interface ou pas, le mieux est de le faire tout de suite, ça ne mange pas de pain.

Sauf quand on se retrouve avec des dizaines d'interfaces à l'utilité douteuse qui font que modifier un argument quelque part nécéssite de changer 6 fichiers différents. 

Dès que la question se pose, c'est qu'il y a un besoin.

Tu dis ça pour ce cas précis, ou c'est un principe général?

Concrètement, faire des artifacts indépendents, ce n'est pas très compliqué et l'IDE (Eclipse, en tout cas) gère bien la mise à jour des dépendences snapshot qui sont également des projets dans le workspace. Toutefois, je pense que c'est un peu plus facile et rapide au début (quand les APIs vont beaucoup évoluer) de tout avoir dans le même projet. Et comme Jean-Sébastien a précisé qu'il mettrait tout en package-private, il n'y aura pas de dépendences malheureuses.

Moandji

[Emmanuel Lécharny]

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

> 2012/6/13 Baptiste MATHUS<bma...@batmat.net>
>
>> Et côté dépendances, d'un point de vue externe, rien ne différencie un
>> "module" Maven d'un projet classique (et en fait, même en interne, c'est
>> pratiquement pareil). Le jar produit aura strictement la même forme et sera
>> utilisable pareil que s'il avait été produit via un projet autonome.
>
> D'après "Maven: The Complete Reference" : "When setting up a multimodule
> project, you are simply telling a project that its build should include the
> specified modules. Multimodule builds are to be used to group modules
> together in a single build."
>
> Pourquoi builder les clients des repositories en même temps que le reste du
> projet? Clairement, les cycles de vie sont différents.

Tu ne sais pas dans l'avenir si tu vas ou pas releaser un module, donc ne te ferme pas une porte.

>
> Emmanuel Lécharny:
>
> C'est un peu comme se demander s'il faut créer une interface ou pas, le
>> mieux est de le faire tout de suite, ça ne mange pas de pain.
>
> Sauf quand on se retrouve avec des dizaines d'interfaces à l'utilité
> douteuse qui font que modifier un argument quelque part nécéssite de
> changer 6 fichiers différents.

Mais non ! Ca n'a rien à voir. Le fait que tu pousse ton code dans un module maven à part ne pose pas de problème particulier. Le module Maven, c'est juste un regroupement logique de classes et d'interfaces. Tu en fais un jar dans ton repo interne (qui ne sera pas déployé), et tes autres modules ne font qu'y faire référence.

C'est juste une unité de compilation, rien de plus.

>
> Dès que la question se pose, c'est qu'il y a un besoin.
>
>
> Tu dis ça pour ce cas précis, ou c'est un principe général?

Principe général. Quand tu commences à te dire "tiens, là, je me demande si je ferais pas mieux de découpler", c'est que t'as déjà de l'adhérence et que tu devrais déjà commencer à découpler.

[Pierre-Yves Ricau]

Un autre avantage du module Maven, c'est de permettre de factoriser la conf Maven (version des deps, process de build) au niveau du projet parent. Enfin... en fait tu peux aussi créer un pom parent utilisé par des projets qui n'ont rien à voir.

L'autre truc pratique, c'est quand tu ouvres un projet parent dans Eclipse, et qu'il te propose d'ouvrir en même temps les 15 modules.

Finalement, le module c'est effectivement très utile quand tu veux une release synchro, et pas trop te faire chier. Un seul "mvn clean package" pour tout builder, un seul "mvn release:prepare / perform" pour releaser...

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.

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

Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr

--
Pierre-Yves Ricau

http://www.piwai.info

[Jean-Sébastien FRANCK]

Merci à tous pour vos conseils. Vous m'avez convaincu de partir sur un découpage en artifact maven dès à présent.

Je suis parti dans un premier temps sur un découpage en module et je trouve que c'est en effet très pratique de pouvoir exécuter une commande maven sur l'ensemble de mes modules à partir du projet parent. Cependant, en terme de réutilisation de module, je ne suis pas convaincu : le fait que le groupId du projet parent soit hérité vers les modules est génant. En effet celui-ci est spécifique au métier de mon projet. Je préfère donc utiliser des modules pour les composants que ne devraient pas être réutiliser, et utiliser un autre projet maven pour les composants qui seront réutilisés.

Merci encore et bonne journée à vous.

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.

[Baptiste MATHUS]

Le 21 juin 2012 09:09, "Jean-Sébastien FRANCK" <jsebf...@gmail.com> a écrit :
>
> Merci à tous pour vos conseils. Vous m'avez convaincu de partir sur un découpage en artifact maven dès à présent.
>
> Je suis parti dans un premier temps sur un découpage en module et je trouve que c'est en effet très pratique de pouvoir exécuter une commande maven sur l'ensemble de mes modules à partir du projet parent. Cependant, en terme de réutilisation de module, je ne suis pas convaincu : le fait que le groupId du projet parent soit hérité vers les modules est génant.

Non. S'il est hérité c'est que c'est toi qui l'a dit. Tu es devant un "modèle objet de projet", donc ton module enfant aura le même groupid que son tant que tu ne le redéfinis pas.

Après tu as raison de te poser la question de la dépendance entre les deux. Si par exemple ce module enfant sera releasé pas dans le même temps que toute la hiérarchie, alors mieux vaut le sortir. Et à ce propos : préfère de loin avoir une seule et unique version pr un même projet multimodules.

[Nicolas Labrot]

La gestion en module est super avec Maven.

Un module B dépend du module A, une modification de A implique de builder complétement A pour pouvoir l'utiliser dans B. Les IDE tentent avec plus ou moins de succès de pallier a cette lacune mais des fois c'est pas jojo.

2012/6/21 Baptiste MATHUS <bma...@gmail.com>

[Moandji Ezana]

2012/6/21 Nicolas Labrot <nit...@gmail.com>

Un module B dépend du module A, une modification de A implique de builder complétement A pour pouvoir l'utiliser dans B. Les IDE tentent avec plus ou moins de succès de pallier a cette lacune mais des fois c'est pas jojo.

Je fais ça souvent avec Eclipse et ça marche très bien. Il reconnaît qu'un artifact correspond à un projet Eclipse dans le même workspace et gère les changements.

Toutefois, si les API vers les repositories dont il était question à l'origine changent tout le temps, c'est qu'ils ne sont pas publiés (et en mode snapshot). Une fois que les API sont stables, il faudrait ne travailler qu'avec des releases, ce qui élimine le problème de rebuilder A ou B (et ne nécéssite pas de modules).

Moandji

[Nicolas Labrot]

Je suis d'accord. Cela pose néanmoins le problème de la reproductibilité du build entre d'un coté Maven, l'outil de build "officiel" et l'IDE qui simule avec plus ou moins de succès le fonctionnement de Maven.

Il convient d'être pragmatique et de découper en module quand vraiment il y a un intérêt, technique, métier, mais aussi en terme de stabilité des API / interfaces. Le découpage ne module peut casser la productivité a coup d'aller retour entre les modules.

Module B dépend de A. Le dev modifie A, pour que B profite de A, le dev doit lancer un install qui lance tous les tests du module A, package, puis copie sur le repo local. Coté B il lance nécessairement compile avec un clean pour faire bonne figure. Si B est une webapp, la phase package rapatrie la dépendance. Bref, bonjour les I/O et la lourdeur.

Le comble étant le couple Maven + JEE. Le bon coté c'est que cela demande, comme du temps des cartes perforées, d’extrêmement bien peaufiner son code et ses tests!

Du coup j'ai convaincu ma boite d'investir dans des SSD et une licence JRebel et parce que j'ai eu le choix sur un nouveau projet je suis passé à Grails (avec encore des problèmes liés à la compatibilité Maven)

2012/6/21 Moandji Ezana <mwa...@gmail.com>

--

[Stephane Maldini]

Intervention quickie, Nicolas peux tu tester Grails 2.1 RC3 avec Maven, le support amélioré est une des priorités de cette version.

2012/6/21 Nicolas Labrot <nit...@gmail.com>

--

Stéphane MALDINI

--

[Nicolas Labrot]

C'est dans ma todo pour ce w-e! ;)

2012/6/21 Stephane Maldini <stephane...@gmail.com>

[Nicolas Delsaux]

2012/6/21 Nicolas Labrot <nit...@gmail.com>

Je suis d'accord. Cela pose néanmoins le problème de la reproductibilité du build entre d'un coté Maven, l'outil de build "officiel" et l'IDE qui simule avec plus ou moins de succès le fonctionnement de Maven.

Il convient d'être pragmatique et de découper en module quand vraiment il y a un intérêt, technique, métier, mais aussi en terme de stabilité des API / interfaces. Le découpage ne module peut casser la productivité a coup d'aller retour entre les modules.

Oh, tiens, ca commence à sentir un peu le petit troll :-) 

Module B dépend de A. Le dev modifie A, pour que B profite de A, le dev doit lancer un install qui lance tous les tests du module A, package, puis copie sur le repo local. Coté B il lance nécessairement compile avec un clean pour faire bonne figure. Si B est une webapp, la phase package rapatrie la dépendance. Bref, bonjour les I/O et la lourdeur.

Je ne vois pas le problème dans ce cas-là.

D'après ce que je comprend (et même si ça va faire beugler de rage Emmanuel), l'un des intérêts des tests unitaires lancés par maven (et donc du build multi-module - exactement comme celui que j'utilise), c'est de pouvoir vérifier la stabilité du build, et rien ne la vérifie mieux que de lancer les tests dnas un paquet d'environnements. Par exemple, au boulot, on lance nos tests sur différentes versions de Windows, et sur Mac, et ça suffit pour nous montrer des erreurs plus ou moins comiques (des repositories non standard qui s'évanouissent dans la nature avec les artefacts qu'ils contiennent - genre le repository java.net,  d'autres qui sont temporairement injoignables, des tests qui marchent en fait parce qu'on a mis le projet dans un dossier sans espaces, ou parce qu'un dossier d ela machine a les bonnes permissions).

Bref, pour moi, même si c'est lourd, c'est la garantie d'un build convergent.

Le comble étant le couple Maven + JEE. Le bon coté c'est que cela demande, comme du temps des cartes perforées, d’extrêmement bien peaufiner son code et ses tests!

Je ne comprend pas trop, là.

Parce que c'est long, tu ne peux pas te permettre de louper ton coup ?

NON.

C'est long parce que c'est découpé en plusieurs modules.

Pour illustrer, j'ai un build comprenant

 - un ejb-jar

 - quelques wars

 - un ear déployé sur un glassfish local

 - du code client Java, C++, et Flex

Evidement, le build complet est long.

Mais l'avantage du build multi-module, c'est que si je travaille sur la partie client Java, je ne recompile tout le projet QUE quand je fais un svn update. Là, oui, c'est long (environ 3 mn). Sinon, ça n'en prend qu'une (le temps de recompiler/tester/package tout le code client).

Et personnellement, je préfère un build long car bourré de tests qu'un build rapide que je teste après à la main.

Du coup j'ai convaincu ma boite d'investir dans des SSD et une licence JRebel et parce que j'ai eu le choix sur un nouveau projet je suis passé à Grails (avec encore des problèmes liés à la compatibilité Maven)

Ah, le SSD, j'aurais aimé. hélas, c'était hors-budget (ca fait toujours bizarre quand ou coûte quelques centaines d'eurs par jour de se faire refuser un ivnestissement de 3 jours de salaire max ...).

--
Nicolas Delsaux

[Nicolas Labrot]

2012/6/22 Nicolas Delsaux <nicolas...@gmail.com>

2012/6/21 Nicolas Labrot <nit...@gmail.com>

Je suis d'accord. Cela pose néanmoins le problème de la reproductibilité du build entre d'un coté Maven, l'outil de build "officiel" et l'IDE qui simule avec plus ou moins de succès le fonctionnement de Maven.

Il convient d'être pragmatique et de découper en module quand vraiment il y a un intérêt, technique, métier, mais aussi en terme de stabilité des API / interfaces. Le découpage ne module peut casser la productivité a coup d'aller retour entre les modules.

Oh, tiens, ca commence à sentir un peu le petit troll :-) 

Module B dépend de A. Le dev modifie A, pour que B profite de A, le dev doit lancer un install qui lance tous les tests du module A, package, puis copie sur le repo local. Coté B il lance nécessairement compile avec un clean pour faire bonne figure. Si B est une webapp, la phase package rapatrie la dépendance. Bref, bonjour les I/O et la lourdeur.

Je ne vois pas le problème dans ce cas-là.

D'après ce que je comprend (et même si ça va faire beugler de rage Emmanuel), l'un des intérêts des tests unitaires lancés par maven (et donc du build multi-module - exactement comme celui que j'utilise), c'est de pouvoir vérifier la stabilité du build, et rien ne la vérifie mieux que de lancer les tests dnas un paquet d'environnements. Par exemple, au boulot, on lance nos tests sur différentes versions de Windows, et sur Mac, et ça suffit pour nous montrer des erreurs plus ou moins comiques (des repositories non standard qui s'évanouissent dans la nature avec les artefacts qu'ils contiennent - genre le repository java.net,  d'autres qui sont temporairement injoignables, des tests qui marchent en fait parce qu'on a mis le projet dans un dossier sans espaces, ou parce qu'un dossier d ela machine a les bonnes permissions).

Bref, pour moi, même si c'est lourd, c'est la garantie d'un build convergent.

Les TU/TI sont indispensables. Devoir les jouer entièrement à chaque modification dans le même processus de développement de mon point de vu bcp moins.

 

Le comble étant le couple Maven + JEE. Le bon coté c'est que cela demande, comme du temps des cartes perforées, d’extrêmement bien peaufiner son code et ses tests!

Je ne comprend pas trop, là.

Parce que c'est long, tu ne peux pas te permettre de louper ton coup ?

NON.

C'est long parce que c'est découpé en plusieurs modules.

C'est justement ce que je voulais dire ;) :

C'est long parce que c'est découpé en plusieurs modules => parce que c'est long, je ne peux pas me permettre de louper mon coup

 

Pour illustrer, j'ai un build comprenant

 - un ejb-jar

 - quelques wars

 - un ear déployé sur un glassfish local

 - du code client Java, C++, et Flex

Evidement, le build complet est long.

Mais l'avantage du build multi-module, c'est que si je travaille sur la partie client Java, je ne recompile tout le projet QUE quand je fais un svn update. Là, oui, c'est long (environ 3 mn). Sinon, ça n'en prend qu'une (le temps de recompiler/tester/package tout le code client).

Et personnellement, je préfère un build long car bourré de tests qu'un build rapide que je teste après à la main.

Le multi module est conceptuellement supérieur, bcp moins avec Maven. Mon experience est surtout dans les webapps.

Je reprend mon exemple appliqué au webapp :

Module B est un war, module A un JAR. Module B dépend de A. Le dev modifie A, pour que B profite de A, le dev doit lancer un install qui lance tous les tests du module A, package, puis copie sur le repo local. Coté B il lance nécessairement la phase package pour construire la webapp, et si vraiment il est consciencieux il joue les tests d'intégration. Comme la webapp est modifiée le dev redéploie. Il rafraichie son navigateur se remet dans le contexte dans lequel il était précédemment.

Mis bout à bout, tu arrives facilement à 5 minutes de perdu. Surtout si la personne switch sur une autre tache.

Du coup j'ai convaincu ma boite d'investir dans des SSD et une licence JRebel et parce que j'ai eu le choix sur un nouveau projet je suis passé à Grails (avec encore des problèmes liés à la compatibilité Maven)

Ah, le SSD, j'aurais aimé. hélas, c'était hors-budget (ca fait toujours bizarre quand ou coûte quelques centaines d'eurs par jour de se faire refuser un ivnestissement de 3 jours de salaire max ...).

Dans ma boite ce fut un lobbying de plus d'1 an ;), qui fut possible car les ordinateurs devaient être changés.

[Laurent Forêt]

2012/6/22 Nicolas Labrot <nit...@gmail.com>

2012/6/22 Nicolas Delsaux <nicolas...@gmail.com>

2012/6/21 Nicolas Labrot <nit...@gmail.com>

Je suis d'accord. Cela pose néanmoins le problème de la reproductibilité du build entre d'un coté Maven, l'outil de build "officiel" et l'IDE qui simule avec plus ou moins de succès le fonctionnement de Maven.

Il convient d'être pragmatique et de découper en module quand vraiment il y a un intérêt, technique, métier, mais aussi en terme de stabilité des API / interfaces. Le découpage ne module peut casser la productivité a coup d'aller retour entre les modules.

Oh, tiens, ca commence à sentir un peu le petit troll :-) 

Module B dépend de A. Le dev modifie A, pour que B profite de A, le dev doit lancer un install qui lance tous les tests du module A, package, puis copie sur le repo local. Coté B il lance nécessairement compile avec un clean pour faire bonne figure. Si B est une webapp, la phase package rapatrie la dépendance. Bref, bonjour les I/O et la lourdeur.

Je ne vois pas le problème dans ce cas-là.

D'après ce que je comprend (et même si ça va faire beugler de rage Emmanuel), l'un des intérêts des tests unitaires lancés par maven (et donc du build multi-module - exactement comme celui que j'utilise), c'est de pouvoir vérifier la stabilité du build, et rien ne la vérifie mieux que de lancer les tests dnas un paquet d'environnements. Par exemple, au boulot, on lance nos tests sur différentes versions de Windows, et sur Mac, et ça suffit pour nous montrer des erreurs plus ou moins comiques (des repositories non standard qui s'évanouissent dans la nature avec les artefacts qu'ils contiennent - genre le repository java.net,  d'autres qui sont temporairement injoignables, des tests qui marchent en fait parce qu'on a mis le projet dans un dossier sans espaces, ou parce qu'un dossier d ela machine a les bonnes permissions).

Bref, pour moi, même si c'est lourd, c'est la garantie d'un build convergent.

Les TU/TI sont indispensables. Devoir les jouer entièrement à chaque modification dans le même processus de développement de mon point de vu bcp moins.

skipTests=true quand t'es pressé et que le module n'est pas de ta responsabilité, c'est utile.

 

Le comble étant le couple Maven + JEE. Le bon coté c'est que cela demande, comme du temps des cartes perforées, d’extrêmement bien peaufiner son code et ses tests!

Je ne comprend pas trop, là.

Parce que c'est long, tu ne peux pas te permettre de louper ton coup ?

NON.

C'est long parce que c'est découpé en plusieurs modules.

C'est justement ce que je voulais dire ;) :

C'est long parce que c'est découpé en plusieurs modules => parce que c'est long, je ne peux pas me permettre de louper mon coup

Mais comme ton découpage est cohérent et bien testé tu travailles sur un module à la fois et donc tu compiles moins et tu testes moins innutilement.

Je suis par contre d'accord pour la partie JEE et les déploiements alourdis par les différents modules maven. Mais c'est plutôt le reflet de la lourdeur du packaging des applis JEE pre 5.

D'ou les TI avec des conteneurs légers embarqués.

 

 

 

Pour illustrer, j'ai un build comprenant

 - un ejb-jar

 - quelques wars

 - un ear déployé sur un glassfish local

 - du code client Java, C++, et Flex

Evidement, le build complet est long.

Mais l'avantage du build multi-module, c'est que si je travaille sur la partie client Java, je ne recompile tout le projet QUE quand je fais un svn update. Là, oui, c'est long (environ 3 mn). Sinon, ça n'en prend qu'une (le temps de recompiler/tester/package tout le code client).

Et personnellement, je préfère un build long car bourré de tests qu'un build rapide que je teste après à la main.

Le multi module est conceptuellement supérieur, bcp moins avec Maven. Mon experience est surtout dans les webapps.

Je reprend mon exemple appliqué au webapp :

Module B est un war, module A un JAR. Module B dépend de A. Le dev modifie A, pour que B profite de A, le dev doit lancer un install qui lance tous les tests du module A, package, puis copie sur le repo local. Coté B il lance nécessairement la phase package pour construire la webapp, et si vraiment il est consciencieux il joue les tests d'intégration. Comme la webapp est modifiée le dev redéploie. Il rafraichie son navigateur se remet dans le contexte dans lequel il était précédemment.

Mis bout à bout, tu arrives facilement à 5 minutes de perdu. Surtout si la personne switch sur une autre tache.

Du coup j'ai convaincu ma boite d'investir dans des SSD et une licence JRebel et parce que j'ai eu le choix sur un nouveau projet je suis passé à Grails (avec encore des problèmes liés à la compatibilité Maven)

Ah, le SSD, j'aurais aimé. hélas, c'était hors-budget (ca fait toujours bizarre quand ou coûte quelques centaines d'eurs par jour de se faire refuser un ivnestissement de 3 jours de salaire max ...).

Dans ma boite ce fut un lobbying de plus d'1 an ;), qui fut possible car les ordinateurs devaient être changés.

[Nicolas Delsaux]

2012/6/22 Nicolas Labrot <nit...@gmail.com>

>
>
> Les TU/TI sont indispensables. Devoir les jouer entièrement à chaque modification dans le même processus de développement de mon point de vu bcp moins.
>

Ah
D'accord
C'est sympa comme discussion, parce que l'intervention de Laurent et
la tienne me font penser à ces histoires de responsabilité des
développeurs.
Vous semblez penser tous les deux que sur une application d'entreprise
un développeur ne travaille que sur un module. Mon expérience est
assez opposée : si je travaille sur une fonctionnalité, je m'en occupe
de bout en bout : persistance dans la base, communication
client/serveur, affichage, ... je sais que je vais tout faire, et donc
passer sur tous modules. Du coup, exécuter tous les tests, je suis pas
contre. Maintenant, si tu veux ne pas t'occuper de tous les modules en
même temps, la bonne solution, c'est de ne plus faire des modules mais
des projets séparés releasés séparément.

>
>
> C'est justement ce que je voulais dire ;) :
> C'est long parce que c'est découpé en plusieurs modules => parce que c'est long, je ne peux pas me permettre de louper mon coup
>

D'accord, parce que quand tu compile ton build multi-module, tu
compile tous les projets (et je dis ça en faisant une release de mon
projet multi-module - ca fait deux minutes que c'est commencé :-) ).

>
>
>
> Module B est un war, module A un JAR. Module B dépend de A. Le dev modifie A, pour que B profite de A, le dev doit lancer un install qui lance tous les tests du module A, package, puis copie sur le repo local. Coté B il lance nécessairement la phase package pour construire la webapp, et si vraiment il est consciencieux il joue les tests d'intégration. Comme la webapp est modifiée le dev redéploie. Il rafraichie son navigateur se remet dans le contexte dans lequel il était précédemment.
>
> Mis bout à bout, tu arrives facilement à 5 minutes de perdu. Surtout si la personne switch sur une autre tache.

D'accord, effectivement, c'est long. Mais est-ce la faut de maven ?
des tests forcément non optimisés en termes de performance (je suis le
premier à faire des tests de brute qui vérifient la cohérenc e de mon
application en torturant le code autour) ? D'un environnement de
déploiement un peu lent (je suis aussi un très mauvais admin
Glassfish, alors forcément, quand je redéploie mon EAR, ca dure des
plombes) ?
Les raisons de la lenteur d'un build sont aussi nombreuses que les
lignes de code dedans, et franchement, je ne jetterai pas la pierre à
maven (sans doute parce que de toutes les solutions de build, c'est la
pire - à l'exception de toutes les autres).
>

--
Nicolas Delsaux