Faut-il commencer à préparer Maven3 ?
Quoi dire de plus que ce qui a déjà été partagé ?
Ces retours sont très instructifs. Ils permettent de faire un bilan de cette branche n°2 (Maven2).
De mon point de vue, la rupture entre Maven1 et Maven2 était vraiment nécessaire. Elle a permis à Maven de prendre son envol, surtout en entreprise.
L'intérêt des systèmes de build n'est maintenant plus à démontré. D'autant plus dans une ère où qualité, processus itératif et réactivité n'ont jamais été autant aux centres de toutes les préoccupations de tous les DSI.
Il est maintenant venu le temps de la pérennité.
De plus en plus de monde remettent en question Maven 2 (http://unmaintainable.wordpress.com/...build-systems/ n'en n'est qu'un exemple parmi de nombreux autres).
Je pense qu'il est temps d'apporter certaines modifications à Maven pour le rendre plus « standard » :
- utiliser et implémenter les normes documentées et reconnues
- utiliser les Frameworks populaires et très largement utilisés (au delà du projet Maven ou quelques autres "petits projets")
Pour moi, Maven (dans le monde de Java) est et sera avant tout un moyen de palier les manques de la plateforme de Sun.
Celle-ci est en train de rattraper son retard, notamment en ce qui concerne la gestion des dépendances (JAva Module aka JAM – JSR 277) qui, d'après les derniers échanges en cours serait rétro-compatible avec OSGi ???
Maven a quant à lui son propre système de gestion de dépendance qui lui est antérieur (même si, il me semble, OSGi existait avant)
C'est à mon avis déjà une très bonne raison pour revoir la gestion des dépendances qui, même si ce n'est pas la seule fonctionnalité de Maven, est une des plus connues.
Qu'apporterait la prise en charge native de JAM ou OSGi pour la gestion des dépendances ?
- Documentation beaucoup plus riche
- -> voir les normes et spécification pour les explications détaillées de la gestion de la transitivité
- Une courbe d'apprentissage moins grande, et un plus grand nombre de contributeurs potentiels
- -> en partant du fait qu'OSGi/JAM deviendrons des notions de bases de tous les développeurs Java
- Une plus grande réutilisation possible d'artefact
- -> « compatibilité native » des artefacts JAR/JAM avec le système de dépendance
- Une complexité moins importante du cœur de Maven
- -> Une grande partie pourra être gérer par d'autres communautés/projet, je pense notamment aux runtimes OSGi déjà existants : Equinox, Felix, et très bientôt la JVM en natif
- Gestion concurrente de plusieurs versions en même temps
- Développement des intégrations aux IDE simplifié
- -> Dépendances transitives déjà gérées en natif (dans le cas d'Eclipse pour OSGi), ou à venir dans Netbeans (dès la sortie de JAM)
- Simplification des POM
- -> Dépendances dans le MANIFEST.MF : plus de redondance avec le POM
- -> à terme, le pom.xml ne contiendrait que ce qui est spécifique à la phase de build et aux rapports (Site, CheckStyle, etc …)
- Pour ceux qui développent des bundles OSGi, (ou plugin Eclipse / Eclipse RCP) :
- -> Enfin un VRAI soulagement !!!
Je serais intéressé pour connaître l'ensemble des sites et sources qui parlent de ces sujets :
- Grandes évolutions prévues pour les futures versions de Maven (2.1, 2.2 et surtout 3.0)
- Evolution du cœur de Maven (prise en compte d'OSGi et/ou JAM pour la gestion des dépendances)
Ressources complémentaires :
Migrer un projet vers maven
Citation:
Envoyé par
fr1man
@ inconnu652000
Je ne comprends pas bien tes reproches.
Une fois ton projet créé sous Maven, tu peux de nouveaux facilement t'en passer.
Je vois pas en quoi avoir commencé le projet avec un ide rend difficile l'utilisation de Maven.
On a migré un projet d'une taille raisonnable sous Maven.
Ok, il y a de boulot, mais rien d'exceptionnel, il faut juste s'y mettre.
Tout n'est peut-être pas parfait avec Maven, mais je lui trouve pas mal d'avantages, comparé à un script Ant qui devient vite illisible, bien plus qu'un pom.xml, enfin, selon moi.
J'ai tenter de migrer un workspace contenant entre 10 et 20 projets (web, ejb, java) avec dépendances cycliques en partant de 0 pour faire de l'intégration continue pas gagner !