Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Maven vers ant ?

12 réponses
Avatar
Patrick Lamaizière
Bonsoir,

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 ?

Merci.

10 réponses

1 2
Avatar
Aeris
Patrick Lamaizière wrote:

Bonsoir,



Bonsoir,

En fait je suis décu par Maven... C'est joli tout beau mais ama c'est
pas terrible.



Ben ça restera ata alors.
Maven est THE outil de référence pour gérer son projet Java, et ça fait
tout, même le café si besoin.
Les plus gros projets Java comme les plus petits utilisent ce tool.

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



Maven n'est prévu que et uniquement pour gérer le cycle de vie de ton
projet. J'ai du mal à voir quel peut être l'utilité de lancer un exe en
plein milieu d'une compilation.
Et ama, si tu as besoin de le faire, c'est sûrement signe que quelque chose
n'est pas bien posé dans ton projet.
Encore plus si ton exec a besoin de stdin/out, qui est signe d'une
intéraction quelconque, ce qui est totalement contradictoire avec le
principe de Maven qui est d'AUTOMATISER les taches (donc sans intéraction
aucune).

Et ça a durée au moins 6 moins avant d'être corrigé, je ne
trouve pas ça très sérieux.



Maven est opensource. Si tu trouves que 6 mois c'est trop long, alors
contribue.
Tous les développeurs des plugins maven sont bénévoles et font ça sur leur
temps libre.

En plus c'est imbitable et assez mal documenté (enfin je trouve).



Maven est un des projets opensource les mieux documentés que je connaisse, y
compris sur ces différents plugins et dépendances (vive mvn site!).

Bon... Là je me bat avec des dépendances, Je gère un tout petit projet
et j'ai autre chose à faire que ça.



Alors tu dois très mal utiliser maven pour gérer ton projet.
Intégrer une dépendance avec maven, c'est 4 lignes de xml dans le pom...

Bref j'ai bien envie de passer à ant, est-ce qu'il y a des automatismes
pour aider ?



Ant est, et de très loin, énormément moins automatisé que Maven.
C'est d'ailleurs pour cela que Maven a été créé initialement.

Merci.
Avatar
Samuel DEVULDER
Le 17/11/2010 20:41, Aeris a écrit :

Maven est THE outil de référence pour gérer son projet Java, et ça fait
tout, même le café si besoin.
Les plus gros projets Java comme les plus petits utilisent ce tool.



Ola.. tout le monde n'est pas sous maven non plus.

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



Maven n'est prévu que et uniquement pour gérer le cycle de vie de ton
projet. J'ai du mal à voir quel peut être l'utilité de lancer un exe en
plein milieu d'une compilation.



Tout dépend ce ce qu'il veut faire. Il cherche peut-etre à avoir des
fonctionnalités type Makefile. Qui sait? Lancer un exe au milieu d'une
compilation: pourquoi pas dans le fond? Il a peut-être besoin de lancer
des outils tiers qui requierent un accès à stdin/out.

Et ama, si tu as besoin de le faire, c'est sûrement signe que quelque chose
n'est pas bien posé dans ton projet.
Encore plus si ton exec a besoin de stdin/out, qui est signe d'une
intéraction quelconque, ce qui est totalement contradictoire avec le
principe de Maven qui est d'AUTOMATISER les taches (donc sans intéraction
aucune).



C'est peut-être ca le fond du pb. Il faudrait détailler ce qu'il veut faire.

Alors tu dois très mal utiliser maven pour gérer ton projet.
Intégrer une dépendance avec maven, c'est 4 lignes de xml dans le pom...

Bref j'ai bien envie de passer à ant, est-ce qu'il y a des automatismes
pour aider ?



Ant est, et de très loin, énormément moins automatisé que Maven.
C'est d'ailleurs pour cela que Maven a été créé initialement.



Tout dépend ce ce qu'il veut faire. Si ca se trouve il veut uniquement
un bon vieux Makefile des familles. Dans ce cas ant est plus proche de
ce qu'il cherche.

sam.
Avatar
Aeris
Samuel DEVULDER wrote:

Maven est THE outil de référence pour gérer son projet Java, et ça fait
tout, même le café si besoin.
Les plus gros projets Java comme les plus petits utilisent ce tool.



Ola.. tout le monde n'est pas sous maven non plus.



Ceux qui ne l'utilisent pas doivent bien se compter sur les doigts de la
main.

Tout dépend ce ce qu'il veut faire. Il cherche peut-etre à avoir des
fonctionnalités type Makefile. Qui sait?



Si c'est avoir juste un bon vieux makefile, alors Maven gère ça parfaitement
rien qu'avec le cycle de vie "install", out-of-the-box et sans plugin
additionnel.

Lancer un exe au milieu d'une compilation: pourquoi pas dans le fond? Il a


peut-être besoin de lancer des outils tiers qui requierent un accès à
stdin/out.

J'ai du mal à imaginer un tel cas, mais s'il pouvait nous éclairer là-
dessus, c'est effectivement peut-être justifiable.

C'est peut-être ca le fond du pb. Il faudrait détailler ce qu'il veut
faire.



+1
Avatar
Samuel DEVULDER
Le 17/11/2010 20:59, Aeris a écrit :
Samuel DEVULDER wrote:

Maven est THE outil de référence pour gérer son projet Java, et ça fait
tout, même le café si besoin.
Les plus gros projets Java comme les plus petits utilisent ce tool.



Ola.. tout le monde n'est pas sous maven non plus.



Ceux qui ne l'utilisent pas doivent bien se compter sur les doigts de la
main.



Pourquoi donc? Pas de dogmatisme. Maven est peut être bien dans certains
cas, mais des gens ne le supportent pas et ont eu des soucis avec lui.

http://www.alittlemadness.com/2007/08/01/the-problem-with-maven/

D'une façon générale comme tous les frameworks, Maven ne marche bien que
si on le suit. Si on doit s'en écarter pour x ou y raisons, ca
fonctionne moins bien. Comme disent les humoristes Chevalier/Laspales:
"Il y en a qui ont essayés, ils ont eu des problèmes". ;-)

Tout dépend ce ce qu'il veut faire. Il cherche peut-etre à avoir des
fonctionnalités type Makefile. Qui sait?



Si c'est avoir juste un bon vieux makefile, alors Maven gère ça parfaitement
rien qu'avec le cycle de vie "install", out-of-the-box et sans plugin
additionnel.



Ben visiblement pas tant que cela car l'exécution d'une commande externe
(bref: ce que fourni le moindre make unix-like) nécessite le plugin exec
qui a des lacunes à en croire Patrick.

Lancer un exe au milieu d'une compilation: pourquoi pas dans le fond? Il a


peut-être besoin de lancer des outils tiers qui requierent un accès à
stdin/out.

J'ai du mal à imaginer un tel cas, mais s'il pouvait nous éclairer là-
dessus, c'est effectivement peut-être justifiable.



Oui.. il doit avoir ses raisons. Si ca se trouve il faut simplement
revoir la compile de son projet avec un makefile unix séparant les
target purement java (===> utilisation de Maven pour ces phases là) des
target "systèmes" requérant l'usage du terminal texte. Tout est possible
et il faut savoir panacher et utiliser le bon outil pour la bonne tâche.

sam.
Avatar
Aeris
Samuel DEVULDER wrote:

Pourquoi donc? Pas de dogmatisme. Maven est peut être bien dans certains
cas, mais des gens ne le supportent pas et ont eu des soucis avec lui.

http://www.alittlemadness.com/2007/08/01/the-problem-with-maven/

D'une façon générale comme tous les frameworks, Maven ne marche bien que
si on le suit. Si on doit s'en écarter pour x ou y raisons, ca
fonctionne moins bien. Comme disent les humoristes Chevalier/Laspales:
"Il y en a qui ont essayés, ils ont eu des problèmes". ;-)



Le but de Maven est de justement "forcer" à respecter des standards de
codage qui sont éprouvés et approuvés, connus pour permettre un build et un
runtime garanti portable et correct dans 100% des cas.

Un projet (pur Java) qui ne rentre pas dans le moule "Maven" a 99.99% de
chances d'avoir un ((très) gros) soucis quelque part.
Je pourrais citer un build machine/développeur-dépendant (classpath
hardcodé), une automatisation du build impossible (pas de récupération des
dépendances), un mélange sources/tests, une génération non-portable des
assemblies (jar/war OS dépendant), les assemblies précédentes contenant des
classes ou des ressources de test, un build non portable, etc...

Dans le lien que tu donnes:
* Les problèmes de stabilités des plugins est un demi-faux problème.
Les plugins standards (compile, site, resources, ...) mis à dispositions via
le superpom n'y sont publiés qu'après pas mal de revue et de test.
Même si on découvre un bug sur une version, 4 lignes de XML vont permettre
de downgrader/upgrader le plugin défectueux.
* Pour les "small tweaks", c'est aussi un faux problème, et même pire, une
mauvaise pratique.
Comme je le dis au-dessus, s'écarter de la norme Maven se justifie très
rarement et est souvent du à un problème de conception et/ou architecture du
projet en amont.
* Pour le "faut faire des plugins", c'est vrai et faux en même temps.
Certes, il est parfois nécessaire d'avoir recours à des plugins.
Mais parmis les 150.000 assemblies proposées rien que sur le dépôt central,
le plugin nécessaire est bien souvent déjà présent et intégrable à Maven en
4 lignes dans le pom.
Et au pire s'il faut écrire un plugin à la main, il est facile d'en écrire
un en quelques lignes sans connaissances très poussées de Maven nécessaire.

Oui.. il doit avoir ses raisons. Si ca se trouve il faut simplement
revoir la compile de son projet avec un makefile unix séparant les
target purement java (===> utilisation de Maven pour ces phases là) des
target "systèmes" requérant l'usage du terminal texte. Tout est possible
et il faut savoir panacher et utiliser le bon outil pour la bonne tâche.



Je +1. A chaque outil sa fonction.

Et justement, Maven n'a pas pour but de lancer des exe, en tout cas en
dehors d'un process de build d'un projet Java.
Mais pour un projet standard Java (jar, war, ear...) relativement complexe,
Maven est utilisable nativement dans 99.99% des cas.
Certes, cela donne parfois un pom un peu long, mais sans aucun "tweak" en
dehors du standard Maven.
Avatar
Philippe
Lancer un exe au milieu d'une compilation: pourquoi pas dans le fond? Il
a


peut-être besoin de lancer des outils tiers qui requierent un accès à
stdin/out.

J'ai du mal à imaginer un tel cas, mais s'il pouvait nous éclairer là-
dessus, c'est effectivement peut-être justifiable.



Comme, par exemple, lancer un outil de génération de code qui n'aurait pas
de plugin Maven...

Cdlt,
Philippe
Avatar
Patrick Lamaizière
Aeris :

Bonjour,

En fait je suis décu par Maven... C'est joli tout beau mais ama c'est
pas terrible.



Ben ça restera ata alors.
Maven est THE outil de référence pour gérer son projet Java, et ça fait
tout, même le café si besoin.
Les plus gros projets Java comme les plus petits utilisent ce tool.



Oui ça n'engage que moi.

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



Maven n'est prévu que et uniquement pour gérer le cycle de vie de ton
projet. J'ai du mal à voir quel peut être l'utilité de lancer un exe en
plein milieu d'une compilation.



Netbean utilise maven-exec pour lancer l'appli à partir de l'ide. Me
demandez pas pourquoi, c'est comme ça.

------------------------------------------------------------------------
Building jtacl-pfconv
task-segment: [process-classes, org.codehaus.mojo:exec-maven-plugin:1.1.2-SNAPSHOT:exec]
------------------------------------------------------------------------
[resources:resources]
[WARNING] Using platform encoding (ISO8859-15 actually) to copy filtered resources, i.e. build is platform dependent!
Copying 20 resources
[compiler:compile]
Nothing to compile - all classes are up to date
[exec:exec]

Et ama, si tu as besoin de le faire, c'est sûrement signe que quelque chose
n'est pas bien posé dans ton projet.
Encore plus si ton exec a besoin de stdin/out, qui est signe d'une
intéraction quelconque, ce qui est totalement contradictoire avec le
principe de Maven qui est d'AUTOMATISER les taches (donc sans intéraction
aucune).



Bien sûr, c'est mon appli qui utilise stdin et stdout. Pas la chaîne de
build.

Et ça a durée au moins 6 moins avant d'être corrigé, je ne
trouve pas ça très sérieux.



Maven est opensource. Si tu trouves que 6 mois c'est trop long, alors
contribue.
Tous les développeurs des plugins maven sont bénévoles et font ça sur leur
temps libre.



Le problème ce n'est pas qu'il n'est pas corrigé (c'est fixé sur le
snapshot depuis plus de 6 mois). C'est que le plugin n'est pas mis à
jour.

En plus c'est imbitable et assez mal documenté (enfin je trouve).



Maven est un des projets opensource les mieux documentés que je connaisse, y
compris sur ces différents plugins et dépendances (vive mvn site!).

Bon... Là je me bat avec des dépendances, Je gère un tout petit projet
et j'ai autre chose à faire que ça.



Alors tu dois très mal utiliser maven pour gérer ton projet.
Intégrer une dépendance avec maven, c'est 4 lignes de xml dans le pom...



Sauf quand le plugin proposé est buggé et que tu dois te ballader sur
les repository pour trouver la version qui marche.

C'est un peu ça mon gros reproche, quand ça marche ça marche bien mais
c'est la chiotte quand y'a un problème.

D'autre part je n'ai que deux dépendances (dont une qui n'est pas dans
maven !), est-ce que j'ai besoin d'un truc aussi compliqué pour ça ?

Et aussi, parce que c'est une appli que je développe en
pointillé et que le developpement est donc long, qu'est-ce que ça
donnera si je reprends mon appli dans un, deux ou trois ans ? Où en
seront les repository ?

Bon, puisqu'il y a des fans de maven ici je vous soumettrais mes petits
problèmes à l'occasion.

Merci.
Avatar
Aeris
Patrick Lamaizière wrote:

Netbean utilise maven-exec pour lancer l'appli à partir de l'ide. Me
demandez pas pourquoi, c'est comme ça.



Et pourquoi ne pas le lancer "à la main" depuis Netbean?
Ca n'a aucun intérêt de lancer l'appli via Maven... Faudrait demander à
Netbean pourquoi ils fonctionnent comme ça.
Sous Eclipse, tout fonctionne correctement sans cet artifice hérétique.

Le problème ce n'est pas qu'il n'est pas corrigé (c'est fixé sur le
snapshot depuis plus de 6 mois). C'est que le plugin n'est pas mis à
jour.



Ben je sais pas, mais tu dis qu'il est fixé en 1.1.2-SNAPSHOT.
Sauf que la 1.2 est déjà dispo depuis longtemps:
http://mvnrepository.com/artifact/org.codehaus.mojo/exec-maven-plugin/1.2

D'autre part je n'ai que deux dépendances (dont une qui n'est pas dans
maven !), est-ce que j'ai besoin d'un truc aussi compliqué pour ça ?



Même ta dépendance "hors Maven" devrait être mise dans ton dépôt perso
(local voire même proxy Nexus par exemple) pour être gérée par Maven
normalement.
Et même avec 0 dépendance, oui, il faut utiliser des outils de build auto,
dont Maven et/ou Ant.

Et aussi, parce que c'est une appli que je développe en
pointillé et que le developpement est donc long, qu'est-ce que ça
donnera si je reprends mon appli dans un, deux ou trois ans ? Où en
seront les repository ?



Ben c'est justement le but des repos. Ils n'auront que plus de dépendances,
pas moins, et ton appli restera 100% opérationnelle.

Bon, puisqu'il y a des fans de maven ici je vous soumettrais mes petits
problèmes à l'occasion.



Avec plaisir :)
Avatar
Philippe
Même ta dépendance "hors Maven" devrait être mise dans ton dépôt perso
(local voire même proxy Nexus par exemple) pour être gérée par Maven
normalement.



Ben, c'est clair... entre Maven ou pas il faut choisir...

Et même avec 0 dépendance, oui, il faut utiliser des outils de build auto,
dont Maven et/ou Ant.



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

Philippe
Avatar
Aeris
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).
1 2