En fait je suis décu par Maven... C'est joli tout beau mais ama c'est
pas terrible.
Déjà le plugin maven-exec (censé exécuter une appli) 1.1.1
présente un bug. Il ne fait pas suivre l'entrée standard au programme
exécuté. C'est ballot quand l'appli exécutée prend ses entrées sur
stdin... Et ça a durée au moins 6 moins avant d'être corrigé, je ne
trouve pas ça très sérieux. En plus c'est imbitable et assez mal
documenté (enfin je trouve).
Bon... Là je me bat avec des dépendances, Je gère un tout petit projet
et j'ai autre chose à faire que ça.
Bref j'ai bien envie de passer à ant, est-ce qu'il y a des automatismes
pour aider ?
Je suis moi même convaincu de l'utilité/supériorité de Maven.
Je dirais simplement à Patrick, si tu ne t'en sors pas avec Maven tentes Ant !
Saches qu'avec Ant: - que tu vas devoir te palucher les scripts à la main - que tu trouveras sur le net tous les exemples possible - que tu maîtriseras l'ensemble du process de build Avec Maven: - tu ne devrais pas te soucier des dépendances - tu ne maîtriseras pas la chaîne de build (du moins si tu ne maîtrises pas la configuration de tes pom).
Dans la pratique, Maven ou pas, il est promordial d'avoir la main mise sur les dépendances pour ne pas avoir de surprise...
Philippe
Aeris,
Je suis moi même convaincu de l'utilité/supériorité de Maven.
Je dirais simplement à Patrick, si tu ne t'en sors pas avec Maven tentes Ant
!
Saches qu'avec Ant:
- que tu vas devoir te palucher les scripts à la main
- que tu trouveras sur le net tous les exemples possible
- que tu maîtriseras l'ensemble du process de build
Avec Maven:
- tu ne devrais pas te soucier des dépendances
- tu ne maîtriseras pas la chaîne de build (du moins si tu ne maîtrises pas
la configuration de tes pom).
Dans la pratique, Maven ou pas, il est promordial d'avoir la main mise sur
les dépendances pour ne pas avoir de surprise...
Je suis moi même convaincu de l'utilité/supériorité de Maven.
Je dirais simplement à Patrick, si tu ne t'en sors pas avec Maven tentes Ant !
Saches qu'avec Ant: - que tu vas devoir te palucher les scripts à la main - que tu trouveras sur le net tous les exemples possible - que tu maîtriseras l'ensemble du process de build Avec Maven: - tu ne devrais pas te soucier des dépendances - tu ne maîtriseras pas la chaîne de build (du moins si tu ne maîtrises pas la configuration de tes pom).
Dans la pratique, Maven ou pas, il est promordial d'avoir la main mise sur les dépendances pour ne pas avoir de surprise...
Philippe
Cédric Chabanois
Moi je pense qu'au contraire maven pour un petit projet, çà marche pas mal. Par contre dès qu'on a des besoins qui ne rentrent pas dans le moule de maven, il faut se battre contre lui et çà devient difficile.
Tout le monde n'utilise pas maven et on voit même de plus en plus d'alternatives telles que gradle par exemple, déjà utilisé par hibernate et par certains projets de spring.
A mon sens, maven a apporté une bonne gestion des dépendances et d'ailleurs c'est utilisé par tous les autres (ivy, gradle ...).
Cédric
Philippe wrote:
Maven pour un petit projet (m�me si cel� semble tr�s bien int�gr� sous NetBeans) c'est parfois moins productif que du Ant.
Si c'est vraiment un petit projet, il y a fort à parier qu'il n'y aura que 3 lignes dans le pom.xml: groupId, artifactId et version. Nul besoin de plugins complexes ou de trucs customs via Maven, on s'en servira uniquement pour la compilation. Sous Ant, il y aura au minimum tout la compilation à scripter à la main...
Maven est un couteau Suisse du build... avec une multitude de plugin plus ou moins maintenus, plus ou moins de qualit�, ... Avec Ant, la mise en place des d�pendance est plus rustique, mais tu ma�trises totalement le build.
Maven pour un petit projet, tu n'auras justement pas besoin de tous ces plugins. Mais le gros avantage de Maven par rapport à Ant est justement sa scalabilité en terme de taille de projet.
En effet, pour un très petit projet (peu ou pas de dépendance, pas de cycle de vie complexe...), Ant reste maintenable (quelques centaines de lignes de XML) mais nécessite de tout développer à la main. Il est orienté "impératif" (ce qu'on a à faire) et non pas "déclaratif" (ce qu'on veut obtenir). Du coup, le jour où on veut gérer beaucoup de dépendances ou intégrer au projet des tests unitaires, un packaging spécifique ou de la génération de code, le build.xml grossi de manière exponentielle et devient bien souvent machine-dépendant.
A petit projet équivalent, Maven représentera 3 lignes (groupId, artifactId + version) + 3 lignes par dépendance, et se contente d'être déclaratif. On dit uniquement ce qu'on souhaite obtenir (telle dépendance, tel .class, tel test, tel package) et Maven se débrouille tout seul pour appeler les bons outils (ivy, javac, junit, zip). Tout le cycle de vie minimal du projet est géré nativement (dépendances, compilation, test, packaging). Par contre à la différence de Ant, si le projet prend de l'ampleur, la configuration de Maven sera toujours de 3+3n!
Un exemple classique d'une application de taille courante: appli 3-tiers + MVC. Je n'appelle pas ça un projet "important" mais sous Ant, le build.xml commence déjà à peser quelques bons milliers de lignes! Gestion des dépendances externes (bases de données, configuration..) et internes (domaine -> dao -> service -> présentation -> ihm), gestion des échecs de test unitaires, packaging, déploiement... Tout est à développer à la main! Sous Maven, cela se résume à 4 pom de 3 lignes + une dizaine de lignes de dépendances.
Le plus gros pom que j'ai jamais pu écrire doit difficilement dépasser les 300 lignes (dont 30% de balises XML inutiles qui vont disparaître sous Maven3 ou informatives (déclaration des développeurs, configuration du scm, ...)), avec en moyenne des pom de 50 lignes (dont toujours 30% de XML inutile/informatif). Sous Ant, 300 lignes, c'est quasiment le minimum vital pour un projet digne de ce nom (dependances externes + dépendances internes + compilation + test + package).
Moi je pense qu'au contraire maven pour un petit projet, çà marche pas mal.
Par contre dès qu'on a des besoins qui ne rentrent pas dans le moule de
maven, il faut se battre contre lui et çà devient difficile.
Tout le monde n'utilise pas maven et on voit même de plus en plus
d'alternatives telles que gradle par exemple, déjà utilisé par hibernate
et par certains projets de spring.
A mon sens, maven a apporté une bonne gestion des dépendances et
d'ailleurs c'est utilisé par tous les autres (ivy, gradle ...).
Cédric
Philippe wrote:
Maven pour un petit projet (m�me si cel� semble tr�s bien int�gr� sous
NetBeans) c'est parfois moins productif que du Ant.
Si c'est vraiment un petit projet, il y a fort à parier qu'il n'y aura que 3
lignes dans le pom.xml: groupId, artifactId et version.
Nul besoin de plugins complexes ou de trucs customs via Maven, on s'en
servira uniquement pour la compilation.
Sous Ant, il y aura au minimum tout la compilation à scripter à la main...
Maven est un couteau Suisse du build... avec une multitude de plugin plus
ou moins maintenus, plus ou moins de qualit�, ... Avec Ant, la mise en
place des d�pendance est plus rustique, mais tu ma�trises totalement le
build.
Maven pour un petit projet, tu n'auras justement pas besoin de tous ces
plugins.
Mais le gros avantage de Maven par rapport à Ant est justement sa
scalabilité en terme de taille de projet.
En effet, pour un très petit projet (peu ou pas de dépendance, pas de cycle
de vie complexe...), Ant reste maintenable (quelques centaines de lignes de
XML) mais nécessite de tout développer à la main.
Il est orienté "impératif" (ce qu'on a à faire) et non pas "déclaratif" (ce
qu'on veut obtenir). Du coup, le jour où on veut gérer beaucoup de
dépendances ou intégrer au projet des tests unitaires, un packaging
spécifique ou de la génération de code, le build.xml grossi de manière
exponentielle et devient bien souvent machine-dépendant.
A petit projet équivalent, Maven représentera 3 lignes (groupId, artifactId
+ version) + 3 lignes par dépendance, et se contente d'être déclaratif. On
dit uniquement ce qu'on souhaite obtenir (telle dépendance, tel .class, tel
test, tel package) et Maven se débrouille tout seul pour appeler les bons
outils (ivy, javac, junit, zip). Tout le cycle de vie minimal du projet est
géré nativement (dépendances, compilation, test, packaging).
Par contre à la différence de Ant, si le projet prend de l'ampleur, la
configuration de Maven sera toujours de 3+3n!
Un exemple classique d'une application de taille courante: appli 3-tiers +
MVC.
Je n'appelle pas ça un projet "important" mais sous Ant, le build.xml
commence déjà à peser quelques bons milliers de lignes! Gestion des
dépendances externes (bases de données, configuration..) et internes
(domaine -> dao -> service -> présentation -> ihm), gestion des échecs de
test unitaires, packaging, déploiement... Tout est à développer à la main!
Sous Maven, cela se résume à 4 pom de 3 lignes + une dizaine de lignes de
dépendances.
Le plus gros pom que j'ai jamais pu écrire doit difficilement dépasser les
300 lignes (dont 30% de balises XML inutiles qui vont disparaître sous
Maven3 ou informatives (déclaration des développeurs, configuration du scm,
...)), avec en moyenne des pom de 50 lignes (dont toujours 30% de XML
inutile/informatif).
Sous Ant, 300 lignes, c'est quasiment le minimum vital pour un projet digne
de ce nom (dependances externes + dépendances internes + compilation + test
+ package).
Moi je pense qu'au contraire maven pour un petit projet, çà marche pas mal. Par contre dès qu'on a des besoins qui ne rentrent pas dans le moule de maven, il faut se battre contre lui et çà devient difficile.
Tout le monde n'utilise pas maven et on voit même de plus en plus d'alternatives telles que gradle par exemple, déjà utilisé par hibernate et par certains projets de spring.
A mon sens, maven a apporté une bonne gestion des dépendances et d'ailleurs c'est utilisé par tous les autres (ivy, gradle ...).
Cédric
Philippe wrote:
Maven pour un petit projet (m�me si cel� semble tr�s bien int�gr� sous NetBeans) c'est parfois moins productif que du Ant.
Si c'est vraiment un petit projet, il y a fort à parier qu'il n'y aura que 3 lignes dans le pom.xml: groupId, artifactId et version. Nul besoin de plugins complexes ou de trucs customs via Maven, on s'en servira uniquement pour la compilation. Sous Ant, il y aura au minimum tout la compilation à scripter à la main...
Maven est un couteau Suisse du build... avec une multitude de plugin plus ou moins maintenus, plus ou moins de qualit�, ... Avec Ant, la mise en place des d�pendance est plus rustique, mais tu ma�trises totalement le build.
Maven pour un petit projet, tu n'auras justement pas besoin de tous ces plugins. Mais le gros avantage de Maven par rapport à Ant est justement sa scalabilité en terme de taille de projet.
En effet, pour un très petit projet (peu ou pas de dépendance, pas de cycle de vie complexe...), Ant reste maintenable (quelques centaines de lignes de XML) mais nécessite de tout développer à la main. Il est orienté "impératif" (ce qu'on a à faire) et non pas "déclaratif" (ce qu'on veut obtenir). Du coup, le jour où on veut gérer beaucoup de dépendances ou intégrer au projet des tests unitaires, un packaging spécifique ou de la génération de code, le build.xml grossi de manière exponentielle et devient bien souvent machine-dépendant.
A petit projet équivalent, Maven représentera 3 lignes (groupId, artifactId + version) + 3 lignes par dépendance, et se contente d'être déclaratif. On dit uniquement ce qu'on souhaite obtenir (telle dépendance, tel .class, tel test, tel package) et Maven se débrouille tout seul pour appeler les bons outils (ivy, javac, junit, zip). Tout le cycle de vie minimal du projet est géré nativement (dépendances, compilation, test, packaging). Par contre à la différence de Ant, si le projet prend de l'ampleur, la configuration de Maven sera toujours de 3+3n!
Un exemple classique d'une application de taille courante: appli 3-tiers + MVC. Je n'appelle pas ça un projet "important" mais sous Ant, le build.xml commence déjà à peser quelques bons milliers de lignes! Gestion des dépendances externes (bases de données, configuration..) et internes (domaine -> dao -> service -> présentation -> ihm), gestion des échecs de test unitaires, packaging, déploiement... Tout est à développer à la main! Sous Maven, cela se résume à 4 pom de 3 lignes + une dizaine de lignes de dépendances.
Le plus gros pom que j'ai jamais pu écrire doit difficilement dépasser les 300 lignes (dont 30% de balises XML inutiles qui vont disparaître sous Maven3 ou informatives (déclaration des développeurs, configuration du scm, ...)), avec en moyenne des pom de 50 lignes (dont toujours 30% de XML inutile/informatif). Sous Ant, 300 lignes, c'est quasiment le minimum vital pour un projet digne de ce nom (dependances externes + dépendances internes + compilation + test + package).
