tests d'integration avec Maven et SoapUI

Les tests unitaires ne sont censées tester qu'une partie du code d'une classe.
Ce qui implique de créer des bouchons, des mocks pour chacun des objets faisant appel à du code extérieur à la classe.

Par contre, il est aussi obligatoire de faire des tests d'intégration, et ainsi de pouvoir tester une fonctionnalité complète.
Pour tester des webservices, l'article présenté ici décrit la manière dont un projet créé avec soapUI et maven peut interagir.
Un truc de plus pour rendre son pom verbeux et incompréhensible, mais c'est plutot utile.

N'utilisez plus les archetypes maven

Allé premier billet après le retour de vacances, youh ouh!
Les archetypes maven créent des projets maven dont la structure est assez vieillote.
Toutefois les archetypes disponibles via codehaus respectent des standards plus récents.

Si vous voulez en savoir plus, regarder cette page.

Le futur des outils de build

On fait beaucoup de reproches à Maven, tout autant qu'à Ant d'ailleurs.
J'attends de voir ce que proposera Maven 3, mais d'autres alternatives émergent.
Elles sont décrites succinctement ici, page dans laquelle on reparle de Gradle, outil pour lequel j'avais déjà pointé un article en juin 2008.

Il semblerait que Gradle prend l'ascendant sur ses "concurrents", mais son utilisation en production, donc sur des gros projets multi-modules, semble pour l'instant osée.

Heritage et Maven 3.0

Et bien voilà, j'apprends qu'un Maven 3.0 est en préparation...
Il serait vraisemblablement tiré de la branche 2.1 de Maven (qui il me semble n'est pas encore disponible, me tromperais-je ?)

Bref, tout ca pour dire que la notion d'héritage est enrichie, je vous laisse découvrir cette update ici.

Maven - compilation et test avec differents JDK

Maven, ce fameux outil qu'on ne présente plus...
Entre ces détracteurs et ces fervents défenseurs la bataille fait rage.

Là n'est pas la question, aujourd'hui, je taggue cet article dans lequel on montre comment on peut compiler et tester une application avec des JDK différents sans avoir à tout refaire.

Ou va Maven

Allé encore un, ah! Maven, outil de build, de gestion de dépendances, de reporting.
Je ne suis que débutant, et je n'ai pas encore le recul suffisant pour en voir les défauts.
Alors je lis, et aujourd'hui, ca a bloggué!
Thèse : maven c'est mort, il y a mieux ailleurs
Anti-thèse : attend la prochaine version, ca va tout déchirer
Synthèse : c'est pas mort, voila les points faibles, des gens y travaillent, ne serait-ce pas trop tot pour l'enterrer.

développer une application cliente BEA

Ca doit être mon premier post, dans lequel je ne transmets pas les news de quelqu'un!
S'en est presque émouvant... ;)

Ma situation :
- développer une console d'administration d'un cluster de serveurs weblogic 10
- avoir une couche de présentation qui fonctionne en mode console

Après avoir créer mes MBeans, puis utiliser un MBeanExporter pour ne pas avoir à créer de MBeanFactory grâce à Spring. Sous eclipse ma librairie fonctionnait très bien, je l'ai donc placé en référence de mon projet dans lequel j'avais la couche de présentation.
Et là, la grande question :
- comment faire pour ne pas avoir à installer weblo sur mon poste et ne pas avoir à mettre en dépendant l'intégralité du répertoire lib de cette même installation.

Et bien la doc de bea est très bien faite!
il suffisait d'aller voir http://edocs.bea.com/wls/docs100/client/index.html
c'est la qu'on apprend la manipulation suivante :
trouver un poste sur lequel est installé weblogic 10.
se placer dans WL_HOME/server/lib
et taper la commande :

   java -jar ../../../modules/com.bea.core.jarbuilder_X.X.X.X.jar
 
 ou X.X.X.X est la version du Jar bien entendu.
 ceci génère un wlfullclient.jar qui fait a peu près 60Mo.
en l'ajoutant au classpath de votre application, elle dispose des librairies suffisantes pour développer
une application cliente.

pour pousser le vice, si vous utilisez maven :

     mvn install:install-file -Dfile=wlfullclient.jar \
                        -DgroupId=weblogic-fullclient \
                        -DartifactId=wlfullclient \
                        -Dversion=10.0 \
                        -Dpackaging=jar \
                        -DgeneratePom=true

et dans votre pom il ne vous restera plus qu'à ajouter la dépendance générée.
Elle est pas belle la vie ?

Gradle - l'outil de build

Ant est vieillissant mais il est possible que son intégration avec Ivy lui confère une seconde jeunesse.
Pour ma part le passage a Maven se fait très bien, je considère cet outil comme très puissant,
même si c'est aussi un fichier XML de plus...
Il y a un grand intérêt à cette description par balise, mais parfois un bon langage de script ca manque!
En attendant, pour ceux qui n'aiment pas Maven, et qui comme moi, pensent que Ant ne se renouvelle pas, peut être que la solution viendra de Gradle.
Cet outil supporte les repository de Maven et Ivy, il y a du script, support le build de multi-projets...
Nous en entendrons peut-être parler bientôt.

une nouvelle version du plugin Maven pour Eclipse

Une nouvelle version du plugin permettant d'utiliser Maven à partir d'Eclipse vient de sortir.
Quatres options sont directement disponibles :
- checkout d'un projet Subversion
- créer un nouveau projet Maven
- créer un nouveau module
- créer un nouveau pom.xml (fichier nécessaire à l'intégration de Maven dans un projet)

La suite de l'article et les explications sont ici.

Utiliser Maven

Le projet que je viens d'intégrer me permet d'appréhender de nouveaux outils.
Le premier de la liste est Maven, alors les recherches commencent.
Maven comment ca marche, qu'est ce que ca permet de faire...
Une partie de la réponse se trouve ici.

J'utilisais il y a quelques années Ant, le build.xml était compréhensible, puis est arrivé Ivy, qu'on utilise avec Ant et qui permet d'obtenir presque autant de fonctionnalités qu'avec Maven.
Un retour d'expérience dans quelques temps ?