Lors de la conf "Maven3" au ParisJug avec Arnaud Héritier, nous avons indiqué que le remplacement du coeur de Maven (Plexus) par Google Guice était repoussé à une version 3.1 de Maven. Les choses semblent cependant s'accélerer.
Pour les besoins de Nexus, Sonatype a développé une couche d'abstraction "Spice" qui permet d'utiliser la syntaxe Plexus avec un conteneur autre, typiquement Google Guice qui est le nouveau moteur de Nexus. Cette expérience réussie donne une sérieuse crédibilité à cette option de migration en douceur.
La même approche a été testée par Sonatype pour Maven3, et Olivier Lamy a importé ces modifications dans une branche du SVN Apache. Ce code passe déjà les tests IT de Maven, même s'il reste quelques incompatibilités liées à de mauvaises pratiques dans certains plugins (modification des composants internes de Maven) que ce nouveau moteur n'autorise plus. Ces signaux plutôt positifs pourraient aider à faire passer Guice comme moteur de Maven dès la version 3.0, ce qui aurait de nombreux effets bénéfiques :
Pour les utilisateurs ou développeurs de plugin, ce changement n'apporte rien de visible, sinon des logs plus clairs quand la configuration est incorrecte - ce qui, avec Plexus, donne parfois le signal de départ pour de longues heures d'analyse. A plus long terme, l'utilisation de Guice permet d'envisager une migration plus profonde des "bons usages" de développement de plugins Maven vers les annotations @Inject (JSR330). Ceci supposera cependant que les plugins qui suivent cette voie soient dédiés Maven3, ce qui promet de longues discutions sur la liste de dev :)
Pour ceux qui veulent embarquer Maven3 dans un autre outil par contre, ce changement est significatif. La configuration de Guice dans ce mode est nettement plus simple. L'intégration de Maven 3 sur Hudson nécessite ce genre d'acrobatie, et Guice sera le bienvenu pour ne pas inutilement compliquer la tâche.
Maven 3 est donc bien en mouvement, mais avec sa très large base d'utilisateurs il ne peut pas se permettre de changements brutaux sans fournir de harnais de sécurité. C'est ce qui le différencie de quelques concurrents comme Gradle, qui apportent de nouvelles idées, mais ont surtout la liberté de tout casser s'ils ont pris une mauvaise orientation.
07 juin 2010
Inscription à :
Publier les commentaires (Atom)
8 commentaires:
Salut Nicolas,
A propos d'annotations, est-il alors prévu que le cœur de Maven passe en Java5 ? Ou cela ne sera-t-il certainement jamais fait pour conserver la compatibilité java 1.4 ?
Le cœur pourrait aussi peut-être passer en java 5, et fournir une version rétro-portée en java 1.4 comme le fait groovy ?
J'ai cherché rapidement sur maven-dev, mais n'ai rien trouvé de probant.
Merci pour les infos.
Je viens de relire les détails de Guice, et c'est spécifique Java 5. Cela signifie-t-il donc effectivement que maven 3.1 passe son cœur en Java 5 ? Ou bien est-ce déjà fait ?
Quid de la valeur par défaut pour la version de java compilé dans le super-pom ? Est-il envisagé de passer à java 5 par défaut ?
Merci encore.
Oui, maven 3 est basé sur Java 5 et utilise annotations et génériques, ce qui aide bien pour clarifier les API.
Rien n'empêche de développer des projets Java 1.4 en maven3. J'utilise pour ma part un JDK6 pour compiler avec Maven une appli Java 1.3. Ne pas confondre le JDK qui fait tourner tes outils avec la version de Java de ton environnement cible !
Tu fais allusion à la valeur du paramètre "source" "target" du plugin compiler, ce qui est sans lien direct avec le runtime utilisé par Maven. La version du plugin induit cette valeur par défaut, la dernière version du plugin change cette valeur pour 1.5 d'ailleurs.
Oui, oui, je ne confonds pas. Simplement, c'est un peu plus dangereux d'utiliser un JDK différent pour compiler qu'en prod, et encore plus pour lancer les TU.
Donc, il serait impossible de lancer un build maven 3 avec un JDK 1.4 sans l'avoir "retroweavé" auparavant.
Pour des gens qui utilisent un JDK 5 sur IBM/AIX, je peux te dire qu'on fait attention à utiliser le plus souvent possible le JDK/JVM de prod :).
Alors, bien sûr, ya Animal Sniffer, si j'ai bien compris son rôle, qui permet d'éviter d'utiliser des API du nouveau JDK, mais c'est quand même plus de boulot de conf pour éviter les problèmes.
@++
tu peux indiquer le chemin d'un JDK précis pour le plugin compiler comme pour surefire. Par ailleurs, avec Tool-chain ça devrait être bien plus simple ... quand ce sera généralisé !
Oui, c'est vrai que je le fais déjà sur un projet. Mais ça impose pour être propre de positionner JAVA6_HOME (par exemple) dans le settings.xml du poste, de l'IC, reconfigurer tous les plugins concernés (au minimum, compiler et surefire, effectivement).
Je vais regarder toolchain, tiens. J'en entends parler, mais je ne sais pas ce que c'est.
Et bien ce sera "non" : http://old.nabble.com/Maven3-with-guice-was-Re:-Maven-3-tests-td28799637.html
Et avec une Jasonade en prime :P
Enregistrer un commentaire