Sonatype va lancer Maven Studio pour Eclipse pour améliorer la productivité des développeurs Java

Ceci est une traduction d'une annonce faite par Sonatype à l'adresse suivante. http://www.sonatype.com/about/in-the-news/20100322

Citation:

---

Un environnement de développement innovant permet à plus de 3 million de développeurs Maven Java(tm) d'améliorer drastiquement leur productivité

EclipseCon - 22 Mars 2010 - Sonatype, gestionnaire du projet Maven et leader dans la fourniture d'infrastuctures de développement logiciel à destination des entreprises, a annoncé aujourd'hui Sonatype Maven Studio pour Eclipse. Le Studio est le seul environnement de développement intégré dans Eclipse spécialement optimisé pour Maven, le standard de fait dans la gestion et la compilation de projets Java, utilisé par plus de 3 million de développeurs Java dans le monde. Le studio accélère la productivité du développeur à travers toute une gamme d'innovations incluant l'embarquement en un clic, rendant les développeurs entièrement productifs en quelques minutes au lieu de quelques heures ou même quelques jours.

"Le processus d'embarquement de nouveaux développeurs dans une logiciel est lent, compliqué et sujet à erreur," dit Mark Driver, vice président et directeur de la recherche chez Gartner Research (NYSE: IT). "La productivité perdue en raison de l'inadéquation et de l'inefficacité du processus d'incorporation et une "taxe cachée" qui amène l'organisation à gaspiller une grande quantité de temps et d'argent."

Rendre un nouveau développeur prêt et opérationnel peut prendre jusqu'à une semaine d'essais erreurs alors qu'ils assemblent un environnement de développement, se battant avec les dépendances du projet, les plugins, les préférences et plus encore. Avec un clic, Maven Studio installe automatiquement et configure tout ce dont le développeur a besoin pour commencer à fournir une valeur ajoutée à son entreprise.

Avec M2Eclipse en open source à son coeur, Maven Studio pour Eclipse fournit un certain nombre d'innovations au delà de l'embarquement en un clic. Celles-ci incluent:

• gestion des licences, pour s'assurer que toutes les entêtes de licence et les fichiers d'attribution sont présents dans le projet, donnant force exécutoire aux termes de la licence;
• intégration de tomcat pour un développement rapide des applications web;
• intégration du wiki confluence, pour permettre aux développeurs de voir et éditer du contenu wiki depuis Eclipse;
• la possibilité de lancer des constructions Hudson et de surveiller ces constructions depuis l'IDE Eclipse

Maven Studio pour Eclipse fournit aussi une intégration poussée avec la plateforme Maven, en incluant du support pour l'approvisionnement d'Eclipse et la matérialisation du workspace, permettant aux développeurs d'automatiquement installer l'IDE Eclipse, faire un check-out du projet source et configurer les préférences. Maven Studio pour Eclipse travaille étroitement avec Nexus Professionnel et s'appuie sur son support du repository Eclipse pour rendre l'embarquement en un clic transparent.

"Maven Studio pour eclipse permet une évolution majeure dans la productivité des développeurs java, éliminant le temps perdu dans le processus typique d'essais erreurs lors de l'assemblage d'un environnement de travail fonctionnel," dit Jason van Zyl, CTO de Sonatype et créateur de Maven. "Chaque organisation qui utilise Maven et Eclipse trouvera le Studio indispensable pour rendre les nouveaux membres d'équipe entièrement opérationnels"

Disponibilité
Maven Studio pour Eclipse sera disponible dans le second trimestre 2010

---

Que pensez-vous de cette initiative ?
Envisagez-vous adopter cet outil ?

Tous les plugins Maven sont aujourd'hui buggués jusqu'à l'os (sur des petits projets, pas de soucis, sur des projets avec pas mal de dépendances, çà merdouille vite).

Maven a de bons concepts mais me fait aujourd'hui perdre beaucoup trop de temps (maintenance ultra laborieuse des POM niveau config plugins / reports (presque plus laborieux que du ANT), plugins parfois capricieux / mal finis (mhh les NPE à tout va, parfois même sur des plugins basiques), erreurs et logs illisibles et parfois absconces, lenteurs, gestion du classpath pour les tests pas terrible sur surefire par défaut, ...), et - surtout (un comble) - résolution des dépendances transitives franchement mal gérée (impredictabilité des versions ramenées si beaucoup de dépendances transitives avec trop souvent des surprises à la clé).

Si Maven 3 ne corrige pas la donne sur tous ces points, je passerai (sans regrets, même si aujourd'hui j'ai beaucoup investi sur Maven) à autre chose.

Donc partant de là non je n'utiliserai pas ce studio Maven, je reste pour l'heure sur Galileo + Maven en ligne de commande (sous Linux), c'est finalement ce qu'il y a de plus productif.

Citation:

---

Envoyé par Killing Joke

Tous les plugins Maven sont aujourd'hui buggués jusqu'à l'os (sur des petits projets, pas de soucis, sur des projets avec pas mal de dépendances, çà merdouille vite).

---

C'est amusant ça, j'ai un projet principal au boulot, constitué de trois gros groupes, chacun ayant des sous projets, des sous sous projets, etc. Je pense qu'on peut considérer ça comme une grosse application vu qu'on sort quand même une 50 aines d'artefacts principaux (sans compter les artefacts de test), qu'on fait des tests automatisés jusque dans le browser et que qu'on a plus de 200 dépendances indirectes. La seule fois où j'ai eu un NPE dans maven, c'est quand j'ai activé les repository alpha pour les plugins maven! On tourne depuis quelques années avec maven, pour rien au monde je ne voudrais devoir gérer ce mastodonde avec du ant!Je n'ai jamais trouvé les plugins "buggés jusqu'à l'OS". Rares en fait ont été les cas ou je suis tombé sur un bug d'un plugin, c'est tout dire.

Quand à la gestion des dépendances transitive, elle est tout à fait prédible et clairement documentée sur le site de maven.

Citation:

---

Envoyé par tchize_

C'est amusant ça, j'ai un projet principal au boulot, constitué de trois gros groupes, chacun ayant des sous projets, des sous sous projets, etc. Je pense qu'on peut considérer ça comme une grosse application vu qu'on sort quand même une 50 aines d'artefacts principaux (sans compter les artefacts de test), qu'on fait des tests automatisés jusque dans le browser et que qu'on a plus de 200 dépendances indirectes. La seule fois où j'ai eu un NPE dans maven, c'est quand j'ai activé les repository alpha pour les plugins maven! On tourne depuis quelques années avec maven, pour rien au monde je ne voudrais devoir gérer ce mastodonde avec du ant!Je n'ai jamais trouvé les plugins "buggés jusqu'à l'OS". Rares en fait ont été les cas ou je suis tombé sur un bug d'un plugin, c'est tout dire. Ca tend au fil des versions à se stabiliser, mais en Maven 2 (je n'ai jamais connu Maven 1), çà a été très très très longtemps complètement instable (et pour moi à l'usage çà l'est encore pas mal aujourd'hui).

Quand à la gestion des dépendances transitive, elle est tout à fait prédible et clairement documentée sur le site de maven.

---

Que tu me dises que là maintenant, avec un projet neuf, un Maven récent (2.2.x), tout tourne bien, je pourrais l'envisager, par contre que çà fasse plusieurs années que tout tourne bien avec Maven, là par contre je n'arrive pas à concevoir comment (avec quelle version initialement ? en faisant des montées de version de Maven ? des montées de version des plugins ?), parce que très honnêtemnet, je ne compte plus les heures perdues pour des erreurs internes Maven / plugin au fil des années (et oui moi aussi j'ai des gros projets avec sous-modules, dépendances vers d'autres projets à nous eux mêmes constitués de sous-modules, etc.), et au au fil des mois, même si on arrive toujours à s'en sortir, il n'y a pas un mois où je n'ai pas un "gros" problème Maven.

Quant à la gestion des dépendances, oui il y en effet une logique prédictible et documentée (encore heureux), mais ce n'est pas pour autant qu'elle est efficace (tu peux te récupérer une version antédiluvienne ou trop récente sans l'avoir demandé, ou avoir une autre version d'un élément en dépendance juste parce que tu as changé l'ordre des dépendances dans ton POM ... sic).

on a commencé avec maven1. Les mauvaises version qui remontent, ca nous est arrivé quelque fois, ca se repère assez vite et c'est généralement un dev qui a fait n'importe quoi dans un pom, ce n'arrive pas quand tu met correctement tes dependency management dans le projet maitre

@Killing_Joke

Citation:

---

je passerai (sans regrets, même si aujourd'hui j'ai beaucoup investi sur Maven) à autre chose

---

Tu as d'autres outils en vue ?

Personnellement je suis satisfait de Maven 2. J'ai quelques soucis par contre avec M2Eclipse et malheureusement je dois souvent passer par la ligne de commande.

Je pense que l'arrivée de Maven Studio ne peut être que bénéfique pour l'intégration de Maven sous Eclipse. J'espère aussi que la gestion de la plateforme Eclipse via Tycho et Maven 3 va s'accélérer.

Mickael

M2Eclipse est vraiment buggué:
* clean sur un jar shadé?
* Arrêt de la résolution des dépendances Workspace sans savoir pourquoi.
* Multiples popup d'arrêt du plugin...

Par contre Maven est un excellent outils dont je ne pourrai plus me passer (j'en suis à me demander si je saurai toujours coder un projet sans).

J'utilise donc les deux: console pour les commandes (mvn...) et le plugin pour la résolution dans l'EDI et l'edition du pom (quand il ne déconne pas).

Le jour où M2Eclipse sera viable, aucun souci, je m'y mettrai, mais jusque là...

oui j'ai les même problèmes avec M2clipse au niveau des dépendances. Rajoutons aussi l'impossibilité de rajouter proprement un sous projet en équipe. Tu rajoute les sous projet, M2Clipse le rajoute aussi comme projet eclipse avec ses dépendnances etc (quand tout va bien ;) ), tu fais un commit du tout, et tes collègue, ben ils ont pas le sous projet qui arrive comme projet éclipse et y a rien dans M2clipse pour l'importer, il reste là, accessible en maven, mais pas importé en eclipse :/

Le plugin IAM, anciennement Q4E, a également des lacunes sur la performance c'est assez dramatique sur un projet d'envergure.

Et encore davantage quand la machine est soumise à un antivirus (ce qui totalement légitime, même si c'est pénible).

Citation:

---

Envoyé par tchize_

oui j'ai les même problèmes avec M2clipse au niveau des dépendances. Rajoutons aussi l'impossibilité de rajouter proprement un sous projet en équipe. Tu rajoute les sous projet, M2Clipse le rajoute aussi comme projet eclipse avec ses dépendnances etc (quand tout va bien ;) ), tu fais un commit du tout, et tes collègue, ben ils ont pas le sous projet qui arrive comme projet éclipse et y a rien dans M2clipse pour l'importer, il reste là, accessible en maven, mais pas importé en eclipse :/

---

Pour cela, il faut faire un commit du sous-projet au bon niveau de l'arborescence SVN, ce que je trouve assez justifié (il serait tout de même bien de définir le chemin par défaut histoire d'éviter les erreurs).

c'est pas le soucis du commit. Tu crée un nouveau workspace, tu demande à M2Clipse d'importer le projet maitre maven et là, pas de soucis. Les fichier sont bien dans le SVN, c'est juste qu'il y a pas d'option dans M2Clipse pour dire "tu vois ce sous projet là? Je veux que tu m'en fasse un projet eclipse, comme tu le fait si bien à l'importation" :)

importer les sous modules comme projet eclipse aussi... C'est vrai que c'est pas l'optimal, mais c'est le seul moyen que j'ai trouvé

Citation:

---

Envoyé par Tcharl

importer les sous modules comme projet eclipse aussi... C'est vrai que c'est pas l'optimal, mais c'est le seul moyen que j'ai trouvé

---

ouais mais là ca deviens le bordel car au final le code est récupéré deux fois du svn, une fois pour le projet eclipse, et une fois dans le sous folder du projet parent qui lui aussi est dans eclipse, et ca fini toujours par un dev qui fait une modif au mauvais endroit

Sinon il y a le tortoisesvn/maven scm plugin pour les checkout et commit, puis ensuite import sous eclipse. Où le choix de son équipe lors d'un développement projet.