Il aura fallut attendre 10 mois pour avoir enfin une nouvelle version de maven 2.0.x.
Cette dernière corrige plusieurs problèmes, et en particulier :
- les dépendances SNAPSHOTs que maven essaie de télécharger même en mode déconnecté,
- l’activation incorrecte des profils.
Petite nouveauté (Brrr j’ai horreur des nouveautés dans ce qui devrait être qu’une version corrective) :
- la possibilité de désactiver en ligne de commande un profil avec la syntaxe
-P!monProfilIdou-P-monProfilId
La branche 2.0.x vie probablement ces dernières versions. On parle plus ou moins d’une 2.0.11 pour corriger encore quelques bugs mais ensuite rien de bien précis. Tout dépendra essentiellement de l’avancement des branches 2.X et 3.X.
Les évolutions (et corrections de bugs importants) sont programmées pour les versions 2.1 ou 2.2. Une première milestone de la version 2.1 est déjà disponible (et utilisable) et une deuxième milestone devrait voir le jour rapidement.
Une ré-écriture plus importante est en cours pour maven 3.0 et devrait corriger les problèmes d’architecture de Maven 2.x (résolution des dépendances de temps en temps approximative, API d’encapsulation inutilisable, …). Une version 3.0-alpha-2 est déjà disponible mais comme le dit Jason, elle est réservée aux masochistes. Il ne prévoit pas que la version 3.0 soit utilisable pour le grand publique avant l’alpha-8.
Téléchargez Maven 2.0.10 : http://maven.apache.org/download.html
MAJ : La release note complète de cette version : http://maven.apache.org/release-notes.html
Il faut vraiment que je prenne un peu de temps pour écrire un post sur ce qui ne va pas avec Maven (non, ça je crois que des milliers de gens l’ont déjà fait). Mais plutôt ce qui n’ira plus avec Maven dans les versions futures de Java EE 6. Le packaging pour beaucoup de specs a (et va) évolué (je pense à Servlet 3 ou EJB 3.1). L’architecture de Maven est trop stricte, trop liée au packaging. Dans Servlet 3 ont aura des fragments de web.xml (optionels) dans des jars (et non des wars). Les EJBs 3.1 pourront être packagé dans des war (et plus dans des jars comme avant)… tout ça avec des descripteurs optionnel dans la plupart des cas (et vive le false). Bref, ça change dans le monde du packaging, et Maven ne change pas bien vite. Faudra-t-il revenir sous Ant ?
Lances-toi. Prends la parole. Tu pourrais publier ces idées sur http://docs.codehaus.org/display/MAVENUSER/Home. A partir de cela on pourrait faire avancer le projet. Je suis d’accord avec toi que la “vue” par packaging a des limitations. Par exemple dans un projet JEE5 si on veut dire a chaque plugin d’être dans la bonne version (compiler en 1.5, servlet 2.5, …) et bien il y en a pour des lignes de config. J’aimerai juste dire a Maven que je fais du JEEx et il se configure partout comme il faut. Mais pour cela il faut pouvoir faire évoluer le POM (pas avant la 2.1 et plus probablement la 2.2) et ajouter des mécanisme de configuration transverse (Toolchains ?? http://docs.codehaus.org/display/MAVEN/Toolchains)
Un truc a revoir dans l’architecture / le pom: configurer le build par phase au lieu de configurer par plugin… Au lieu de:
On aurait:
Salut Sébastien. J’ai l’impression que ton copie/colle a bugger 🙂
On peut aujourd’hui configurer un plugin de manière globale ou pour une execution donnée. Est ce que cela ne suffit pas ? Ton problème c’est par exemple sur surefire si tu l’utilises en tu et en ti ?