En substance : wicket est devant pour peu qu’on fasse bon usage des mécanismes proposés (le LoadableDetachableModel principalement).

De mon expérience personnelle, cela est aisément réalisable et, encore plus important, encapsulable. La complexité est alors cachée, reste plus qu’à s’assurer que les développeurs utilisent le même modèle (qui se retrouve dès lors utilisé dans 95% du code).

En somme, quelque chose de facilement réalisable.

Cordialement,
Joseph

Pour moi, oui le serveur d’app doit faciliter le travail de tous les corps de métier, équipe de dev compris et non uniquement la prod
Glassfish et Spring TC Server s’oriente vers ce choix :
- démarrage rapide pour accélérer le cycle code/run/test
- intégration aux IDE
- déploiement facile

Reste à voir si c’est à l’équipe Glassfish de proposer ce plugin Maven ou à la communauté.

Par ailleurs, tu as bien raison : Maven n’est pas une obligation.

Glassfish est une implémentation de Java EE 5 (maintenant 6). Pas Jetty ou Tomcat. Les points de comparaison sont limités.

Cet article peut être utile pour utiliser Glassfish avec Maven. Mais le manque de support pour lancer Glassfish via Maven ne m’apparaît pas comme un souci. Est-ce à Glassfish de fournir ce support ?

Je n’ai pas eu ce cas d’utilisation avec les profils Jetty en dehors d’un Pom War.
Si tu as trouvé une solution, je suis preneur.

Tom

Je cherche un moyen de lancer Jetty en utilisant des profils de test déclarés dans un pom parent au projet web que je veux tester.
Ceci est-il possible ? Il ne me semble pas que l’héritage de profil existe dans Maven.
Du coup, j’utilise plutôt le plugin tomcat qui permet de lancer le serveur en se placant sur le projet parent (détecte automatiquement les modules web qui en dépendent) et visiblement ceci n’est pas possible avec jetty (obligé de lancer le plugin sur un projet war)

Une idée ?

Merci

Comme Tom, j’ai jamais considéré Groovy comme crédible face à Ruby, en terme de language, même s’il ma intéressé aussi avant que JRuby existe. En plus, je en compte pas comme vous, je considère qu’aprendre des choses comme un langage ouvre l’esprit et rend in fine plus productif. J’ai aussi super appris le Python par la suite (pour OpenERP) et pas de regret non plus même si je condière Jruby supérieur.

JRuby a été un facteur très important vu que j’aimais quand même relativement Java (surtout après le C/C++). J’ai donc commencé à utiliser JRuby dès la fin 2006, aujourd’hui c’est la meilleure implémentation de Ruby…

J’ajoute que la tronche qui a donné ses lettres de noblesses à JRuby, Nutter, est en ce moment en train de perfectionner 2 dérivés de JRuby qui à mon sens font perdre toute valeur à Scala. Il s’agit de Duby et Surinx. Duby est un genre de Scala mais qui utilise les type Java uniquement avec 90% la syntaxe de propre de Ruby, Duby a de l’inférence de type et tourne à la même vitesse que Java. Surinx est comme Duby mais il va exploiter le invokeDynamic de Java7 pour permettre des appeles dynamiques comme sur Ruby (mais tj avec les types java et des apples à 90% statiques et du coup une perf mi chemin entre celle de Duby et de JRuby. ces 3 langages utilisent des bases de codes communes crédibles et vont s’intégrer à la perfection. Il y a les slides qui se balades, mais je sais plus ou, sinon regarder:
http://thestrangeloop.com/blog/09/08/18/speaker-focus-charles-oliver-nutter-ruby-mutants

A bon entendeur…

J’ai envisagé Groovy, Scala et Ruby avant de me décider.
Comme conclusion, le critère “Hors de la JVM” a été un aspect important.

Mon raisonnement est que se concentrer uniquement sur l’écosystème Java rétrécit notre vision des choses.
Par exemple, j’ai l’impression que un framework comme Rails n’aurait pas pu sortir en premier sur Groovy.

Je me suis rendu compte de certaines divergences de pensées lors du TDW camp (travailleurs du Web) où j’ai côtoyé pas mal de monde qui faisait du Php et qui n’ont pas du tout les mêmes problèmes de complexité à résoudre pour répondre à un même besoin en java.

Pour revenir à Ruby, j’ai pris mon courage à deux mains pour m’y mettre. Mais c’est très consommateur de réapprendre tout un environnement (quels sont les frameworks, les API, les projets, les gens…).

Pour résumer mon propos : j’ai choisi Ruby presque pour ses conditions externes que pour le langage lui-même. Le sentiment de liberté est fort dans le monde Ruby. Un peu comme le “Fork Me!” de GitHub.

Tom

Je vais peut être tenter l’expérience Tellurium pour certains tests, afin de voir les avantages.
Je vous ferais part de mes retours éventuels.