15 décembre 2007

mvn eclipse:eclipse

En passant de maven 1 à maven 2, on corrige (entre autre) un défaut de maven 1 : on peut faire un "clean" sur un projet qui n'a encore jamais été compilé. Quel intérêt ? sur un serveur d'intégration continue, le tout premier build ne pouvait pas être du type "maven clean jar:install" !


Un autre bug gênant : pour configurer son IDE préféré (Eclipse dans mon cas, tout simplement parce que je n'ai pas pris le temps de tester Idea ni Netbeans !), on lance "mvn eclipse:eclipse". Et la, crac, la simple présence d'un projet EAR fait planter le build. La faute aux plugin eclipse qui exécute la phase generate-sources, seul moyen d'identifier tous les répertoires de code généré. On doit donc faire un "mvn install" avant de pouvoir bosser sous Eclipse. Mais alors, si le code sous SVN est buggé et ne compile pas ?... reste le bloc note pour corriger !

Je cherche un moyen de fixer ce problème. Deux options :
  • trouver une astuce pour que la résolution des dépendances n'échoue pas. Par exemple, enregistrer chaque module comme "artifact virtuel" pour qu'il ne soit pas recherché sur le repository. Seulement les composants interne de Maven sont un peu obscurs et pas trop ouverts à ce genre de "hack".
  • faire évouler l'API des plugins maven ("mojo") pour que le plugin eclipse puisse identifier les plugins générateur et le répertoire qu'ils créent. Pourquoi pas profiter du passage à maven 2.1, mais encore faut-il convaincre la communauté :-/

J'aurais peut-être du commencer par quelque chose de plus simple...

2 commentaires
Libellés : ,

quel framework web pour l'avenir ?





Le constat est clair : fàce aux alternatives "modernes", Struts fait office de mammouth, au sens "pachiderme" du terme. Top de configuration et de classes à développer, même pour un simple hello world, alors pour coder une transaction de prise de commande étalée sur 5 écrans...

Problème, la relève s'avère un peu trop prolifique. Faut-il suivre Struts², Spring MVC - selon une approche assez classique - faire le pari des "Ruby-on-Rails-like" (Grails, Sails, Trails et j'en passe) ou encore passer à tout autre chose (Wicket ?). Sans évoquer l'option JSF, avec ou sans jboss Seam, ou Google Web Toolkit. Et pourquoi pas du pur HTML + JavaScript + services REST ?



Alors ? J'ai du mal a me faire une opinion tranchée, surtout que je n'ai mis en oeuvre aucun de ses frameworks à une échelle significative.

Un constat cependant : en tant que prestataire de service, je dois convaincre mon client du bien fondé d'un choix. Sails (au hasard) est peut être très bien, mais quel dirigeant en a entendu parler ?

Deuxième aspect, la taille de la communauté et/ou la documentation disponible. De ce point de vue, Struts2 et Spring MVC sont les plus vendeurs, avec Seam et GWT.

Troisième point, la capacité d'adaptation des développeurs. Exemple de Grails : même si Groovy n'est pas bien compliqué, ça fait un langage de plus à connaître, et de nombreux mécanismes "auto-magiques" à apprendre. De ce point de vue le duck-typing est sans doute super pour les cracks, mais surtout source de bugs et de difficultés pour les autres, qui préfèrent le bon vieux "ctrl+Expace" pour obtenir la liste des méthodes disponibles.

Enfin, les possiblités de sortie. Si le framework ne suffit pas, comment faire ?

De cette réflexion, de mon point de vue Struts2 sort grand vainqueur :
  • le simple nom "struts" est définitivement vendeur. Peut importe que le code n'ait rien à voir avec Struts 1, je sais que je n'aurais pas à batailler pour le vendre, ni à mon chef, no à mon client. Deux de mes plus gros soucis en moins ;-p
  • la communauté webwork était assez limitée, celle de Struts est énorme, même si une grande partie reste utilisatrice de la première mouture. La doc et les bouquins sur le sujet commence à s'étoffer, et devrait atteindre le seuil critique.
  • pour le développeurs lambda, passer à Struts2 va nécessiter de "désapprendre" Struts 1, mais comme struts 1 était trop souvent mal employé, ça ne sera pas si difficile ;-p. Le principe de base reste de type MVC, donc le fossé à franchir est raisonnable. Grails, JSF ou GWT nécessitent de revoir complètement les notions sur l'architecture d'une application web.
  • quand à dépasser les limites de Struts2, le nombre impressionnant de "plugins" qui viennent le compléter parle de lui-même. Déjà, smartURL (futur codebehind) nous promet de réduire au strict minimum la conf nécessaire. Scope nous apporte du Seam-like, avec le support des conversations et la "bijection" des données manipulés. REST permet de coder facilement des service web léger (je n'ai rien vu pour SOAP), GWT permet de s'intégrer avec une IHM GWT, etc.
L'avenir me donnera peut-être tort (je viendrais alors éditer cet article pour effacer toute preuve), mais parier sur Struts2 n'est probablement pas le pire des choix, même si ce n'est pas non plus le plus courageux.

Et JSF ? Un standard, ça devrait rassurer ! D'une part j'ai du mal à rentrer dans la logique de JSF (un peu compliqué tout ça), d'autre part je n'aime pas du tout les JSP "à la JSF", totalement illisibles à mon gout. Et avec Facelets ? Pour être honête, Facelets + Seam serait mon second choix, disons plus "engagé" que le très sage "passons de Struts 1 à Struts 2".

Pas simple tout ça ... d'un autre côté, on ne pourra pas se plaindre d'être forcé à utiliser une solution, comme c'était le cas avec ces magnifiques EJBs 1.x qui m'ont tant fait râler.
1 commentaires
Libellés : ,

14 décembre 2007

premiers commits

J'ai effectué mes premiers commits sur Archiva, afin d'intégrer un meilleur support de Maven1.

Comme toute première fois qui se respecte, j'ai généreusement merdé :
  • commit "mis à l'index" faute de commentaire @since dans le code
  • build Continuum planté, suite à un cafouillage sur archiva-configuration

Heureusement mes petits camarades sont tolérants et m'ont gentiment remis dans le droit chemin, avec quelques indications sur les bonnes pratiques @Apache.org.
1 commentaires
Inscription à : Articles (Atom)