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
- -> Géré actuellement par ClassWorld (http://classworlds.codehaus.org/)
- 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 :
Partager