Posts in maven

JAXRS, Netty Et Bien Plus Encore... Mode D'emploi...

left-small

L'informatique évolue constamment et c'est également le cas des architectures qui ont tendance à s'orienter de plus en plus vers l'utilisation de services REST. Ces services REST doivent, en outre, être de plus en plus véloces afin de pouvoir répondre à une charge de plus en plus forte (que ce soit d'un point de vue temps de réponse mais également d'un point de vue charge suportée). C'est dans ce contexte que des solutions comme Restlet ou RestX (pour n'en citer que quelques-unes) ont vu le jour.

En effet, en plus d'offrir la possibilité de servir des services REST, elles s'appuient sur des framework dont la particularité est d'offrir des traitements non bloquant sur les entrées/sorties (NIO).

C'est dans ce contexte que cet article parlera principalement de Resteasy-Netty 3 (la version 3 a été utilisé en raison de contraintes techniques (connexion à Apache Cassandra dont le driver utilise Netty 3)).

Cependant, ce ne sera pas le seul protagoniste car, comme on verra par la suite, il est très simple à utiliser…

Le vrai sujet de cet article est, en fait, comment il a été possible d'ajouter d'autres framework comme Swagger ou Jolokia à Resteasy-Netty 3.

Cet article sera découpé en deux parties :

  • Besoin et conception
  • Mise en oeuvre

Le code se trouve sur Github ici.

in java, jmx, jolokia, maven, metrics, netty, performance, rest Read on →

FluentLenium Et Cucumber JVM... Complément Et Precision

left-small

Dans mon article précédent, j'avais tenté d'expliquer comment il était possible d'intégrer les frameworks Cucumber JVM et Selenium au travers de FluentLenium.

En effet, pour rappel, FluentLenium permettait d'abstraire Selenium en lui offrant une API plus fluent mais également en lui apportant nativement ce qu'il préconise, à savoir le Page Object Design Pattern.

Pour ce faire, j'avais proposé d'utiliser la délégation de l'initialisation de FluentLenium à une classe tierce injectée via le mécanisme d'injection de Cucumber JVM.

Cependant, suite à discussion avec la créatrice de FluentLenium (à savoir Mathilde), on s'est rendu compte que l'axe utilisé était légèrement biaisé (même s'il fonctionnait…).

Cet article revient donc sur ce point en proposant une solution plus simple mais présentera également comment il est possible de tester le scénario Cucumber avec différents navigateurs et il y aura un petit mot sur l'utilisation de navigateurs déportés (via les RemoteWebDriver de Selenium 2).

Pour ce faire, il sera découpé en 3 parties qui couvriront des usecases différents se traduisant donc par des implémentations différentes :

  • cas de tests pour un site simple,
  • cas de tests pour un site complet,
  • cas de tests multi-navigateurs pour un site complet.

A noter que je ne reviendrai pas sur les principes des différents frameworks/concepts mais juste sur comment il est possible d'implémenter ces différents usecases.

A noter également que l'article précédent aurait pu être modifié mais qu'en raison du nombre important de changements, il était plus simple d'en initier un autre…

in fluentlenium, intégration continue, java, maven, selenium Read on →

FluentLenium Et Cucumber JVM Sont Sur Un Bateau...

left-small

Dans un article précédent, j'avais abordé comment il était possible de démarrer une application web dans un conteneur de Servlet de manière embedded au sein de la phase integration de Maven. Bien sûr, cela n'a pas été fait que pour l'exercice de style et il y avait une petite idée derrière : pouvoir exécuter des tests d'acceptance en mode boite noire sur l'application.

Pour faire les tests d'acceptance, le choix de Cucumber JVM a été fait afin de permettre l'expression de tests d'acceptance avec une sémantique utilisant le pattern Given/When/Then mais également afin de permettre à des non développeurs de comprendre/écrire les scénarii de test à exécuter.

L'application à tester étant une application web, un besoin s'est fait sentir de tester la partie rendue. Dans cet article, lorsque l'on parlera de tester la partie rendue, il sera question de vérifier que l'élément recherché se trouve bien dans le document html remonté dans le navigateur web. Pour rappel (cf. le paragraphe Contexte de ce post), l'application testée s'appuie sur un framework web java de type Struts2.

Aussi, il ne sera pas question, ici, de tester le rendu dans différents navigateurs.

Il a été décidé de partir sur une solution s'appuyant sur un runtime à base de Selenium : en effet, un besoin latent étant, à terme, de tester le rendu de l'application web sur les différents navigateurs, cette solution semblait correspondre le mieux aux besoins.

Bref, passons ce besoin pour revenir à notre objectif premier, à savoir, vérifier la présence des éléments dans l'arbre DOM remonté par l'application web.

Pour résumer, il a été décidé de partir sur :

  • Cucumber JVM pour la partie représentation/écriture des scénarii,
  • Selenium pour la partie exécution des tests.

Cependant, la syntaxe sur la partie WebDriver de Selenium 2 étant assez verbeuse, il a été décidé d'utiliser le framework FluentLenium qui offre une API plus simple et plus naturelle (enfin plus fluent quoi! ;–) ). En outre, en plus d'une API plus facile d'utilisation, la notion native de Page de FluentLenium poussant à mieux découpler la représentation d'une page et son test, cela a joué en sa faveur ;–)

Ainsi, cet article présentera comment il a été possible d'intégrer Cucumber JVM avec FluentLenium afin de pouvoir faire tourner des tests avec Selenium.

A noter que je ne m'attarderai pas, dans cet article, à présenter exhaustivement les différents protagonistes mais seulement les quelques points qu'il est nécessaires de connaitre afin d'intégrer ensemble ces différents framework.

[update] Suite à discussion avec la créatrice de FluentLenium, un autre article a été initié et apporte de nombreux compléments mais également correction à cet article. Pour en savoir, plus, rendez vous ici

in fluentlenium, intégration continue, java, maven, selenium Read on →

Démarrer Une Webapp en Mode Embedded Avec Maven

left-small

La mouvance actuelle dit que tout projet qui se veut un minimum industrialisé doit pouvoir détecter les anomalies au plus tôt. Pour ce faire, il est dit qu'il doit disposer de tests, qu'ils soient unitaire, d'intégration, fonctionnel ou d'acceptance.

Pour adresser le problème des tests d'intégration, il est souvent utile de démarrer l'application cible de manière embedded.

Cette article montrera comment il est possible de faire pour un contexte donné.

En outre, vu que ce blog me sert également d'aide mémoire, cela me donnera une excuse pour marquer noir sur blanc des informations que je peine toujours à retrouver… ;–)

Pour les habitués de ce blog (oui, je sais, cela fait un moment que je n'ai rien écrit… ;–) , le plan sera toujours le même : dans un premier temps, le contexte sera décrit puis des ébauches de solutions seront proposées jusqu'à tendre vers celle qui a été retenue.

in intégration continue, java, jetty, maven, tomcat Read on →

Précompiler Ses Jsp

left-small

Parce qu'il est parfois nécessaire de valider ses jsp, cet article fera un petit retour sur comment cela peut être mis en oeuvre.

Oui, je sais, les jsp c'est has been me diront certains… Cependant, il ne faut pas oublier que dans le monde Java, cela reste une des technologies indispensables quelle que soit le framework utilisé (j'entends par là dans le cas où les pages sont rendus dynamiquement par une technologie java).

Ayant eu récemment à intégrer une phase de validation des jsp maintenus principalement par des équipes “front” n'ayant que peu de connaissance en Java, ce rapide retour d'expérience tentera d'exposer les quelques points qui ont pu me poser problème et en l'occurrence les quelques-unes des différentes solutions possibles pour traiter ce point.

Aussi, dans une première partie, je présenterai le contexte, pour ensuite aborder trois des solutions possibles (et relativement récentes car il en existe plusieurs dans différentes versions…) pour valider les jsp.

in ant, intégration continue, java, jsp, maven, tomcat Read on →

Découpage De Projets : Projet vs. Modules

left-small

Lorsqu'un projet débute, il est important (à mon avis) de se poser la question sur la façon dont celui-ci sera découpé. Pour être plus précis, il existe deux types d'approches :

  • le découper fonctionnellement,
  • le découper techniquement.

En outre, en plus de ce type de découpage, il est également important de s'interroger sur la façon dont il sera représenté dans le SCM : faut-il tout mettre dans le même projet (au sens SVN ou git du terme) en utilisant éventuellement des sous modules maven si c'est ce dernier qui est utilisé, ou faut-il en créer plusieurs?

C'est de ce dernier point dont il sera question dans ce court article qui présentera l'avis que j'ai pu me faire concernant le découpage technique du projet ie. s'il vaut mieux le découper en projets séparés ou en module (au sens maven du terme).

Il s'agit d'une opinion très personnelle qui peut ne pas être partagée par tous mais je trouvais intéressant de fournir mon humble avis et de le marquer noir sur blanc. Si je venais à dire des bêtises, au moins, cet article servira d'amorce à la discussion ;–)

in architecture, avis, java, maven, réflexion, soa Read on →

Maven : Créer Une Branche - Mode D'emploi

left-small

Il y a un moment déjà, j'avais fait un article sur le plugin release oh combien pratique dans notre utilisation de maven. J'y avais mentionné les 2 goals prepare et perform qui sont les plus connus et qui, pour rappel, permettent de :

  • vérifier que lors du lancement du processus de génération du livrable, le code est bien conforme à ce qui se trouve sur le SCM,
  • tagger le code source à partir duquel le livrable est produit et permettant ainsi sa reproductivité,
  • incrémenter le numéro de version des poms,
  • générer le livrable,
  • et le déployer sur le remote proxy repository.

Dans cet article, je me concentrerai sur un goal du plugin release malheureusement assez méconnu mais qui est tout aussi pratique et important (à mon sens) que ses 2 comparses prepare et perform. Il s'agit du plugin branch.

in java, maven Read on →

Petit Focus Sur 2 Plugins Maven

left-small

Bon, ça fait un moment que je n'ai rien écrit… je n'ai pas foncièrement d'excuses si ce n'est que j'ai été pas mal occupé sur un projet sur lequel j'essaierai de faire un petit retour dans un futur proche…

En fait, dans ce rapide post, je tenais à faire partager 2 “petits” plugins maven que j'ai eu l'opportunité de découvrir récemment par le biais de 2 Olivier :

Les deux plugins sont les suivants :

En fait, je ne rentrerai pas en détail dans les 2 plugins Maven qui, pour un, est assez connu mais je me contenterai juste de décrire les fonctionnalités que j'ai appréciées.

N'étant pas expert sur ces derniers et n'ayant pas creusé dans tous les paramétrages, j'espère que la présentation qui suit ne dira pas trop de bêtises… ;–)

in intégration continue, java, maven Read on →

Jetty, Maven Et JMX

left-small

Vous avez peut être remarqué que ces derniers temps, j'étais très Maven et JMX. Cet article ne déroge pas à la règle puisque je vais parler de… Maven et de JMX.

Enfin pour être plus précis, je vais montrer comment il est facilement possible de déployer une application web dans le conteneur embarqué Jetty via Maven en activant la couche JMX afin de pouvoir tester de manière intégrée cette couche.

Pour ce faire, je présenterai dans un premier temps le contexte, puis comment cela peut être mise en œuvre. Bien sûr, cet article montre comment j'ai fait mais il ne représente pas la seule manière de faire… ;–). En outre, il ne présente rien de novateur mais je me suis dit que cela pouvait toujours être utile afin d'éviter de faire perdre du temps à d'autres personnes.

in java, jetty, jmx, maven Read on →

Maven Pour Les Nuls... Les Archetypes

left-small

Dans le cadre d'une problématique d'une usine logiciel, il peut s'avérer utile de posséder un patron ou template de projet qui fournit les “bonnes” pratiques que doivent respecter l'ensemble des applications du projet.

Bien sûr, notre cher IDE est capable de générer un joli patron de projet. Cependant, il reste toujours nécessaire de modifier la configuration du projet pour y mettre, par exemple :

  • la version de jdk,
  • les libs utilisées (comme mockito par exemple),
  • optionnellement, la configuration de plugins,
  • optionnellemet, l'url du SCM,
  • ou tout simplement, la référence à un projet parent qui permet de définir, par exemple, la version des librairies ou des plugins utilisés.

Le hic, c'est que, généralement, cela fini par de jolis copier/coller dont le résultat diffère, bien sûr, en fonction du projet qui a servi de template. Le résultat : le syndrome du téléphone arabe sachant qu'en plus, on n'est même plus capable de savoir qu'elle était la référence du départ… embêtant tout ça… surtout pour un projet se voulant industriel…

En outre, posséder un patron de projet peut également s'avérer utile si vous êtes amené à POCer des frameworks ou faire des projets perso chez vous…

Vous l'aurez compris, cet article se focalisera sur les projets construits sur maven où les notions de dépendances, de plugins, d'informations projet sont présentes dans le pom.

Cet article a donc pour objectif de montrer comment il est possible de créer un archetype maven qui permet de répondre à ce problème.

Le use case sera simple puisque je m'appuierai sur la création d'un archetype simple pour mes besoins personnels afin de me fournir un patron normalisé (selon mes normes) me permettant de démarrer un POC rapidement pour un artifact de type jar et cela dans le seul but de ne pas avoir à faire moultes copier/coller… ;–)

A noter qu'il n'y a rien de révolutionnaire dans cet article pour toutes les personnes qui ont quelques connaissances de base en maven mais qu'il peut s'avérer utile (enfin j'espère) pour les autres… ;–)

in archetype, java, maven Read on →

Les Repositories Manager Pour Les Nuls... Focus Sur Nexus

left-small

Cela fait un moment que je n'ai pas bloggé faute de temps mais également d'inspiration… (ça c'est dit et ça, on s'en fout d'un coté ;–) ) Cet article parlera des repository manager. Rien de nouveau à l'horizon puisque la problématique et les solutions existent depuis un moment mais ayant dû en mettre un en place récemment et au vu de nombreuses questions que l'on m'a posées, je vais ici coucher sur “papier” ce qu'est un repository manager, c'est à dire quelques uns de ses concepts clés. En outre, cela me servira également d'aide mémoire et je me dis qu'une piqûre de rappel ne fait jamais de mal… ;–)

Pour ce faire, je vais m'appuyer sur l'excellent repository manager Nexus de Sonatype et plus particulièrement (comme à mon habitude… ;–) ) sur sa documentation officielle.

Par contre, je ne reviendrai pas sur les concepts de base de maven comme la définition de ce que sont les repositories local et distant.

Enfin, ici, j'utiliserai la même dénomination que le guide Nexus pour le terme organisation qui devra être pris au sens large du terme (entreprise, projet open source, poste local, …).

in maven, nexus Read on →

Le Plugin Release (Un Peu) Démystifié

left J'ai déjà longuement parlé de maven 2 dans des posts précédents (Petites astuces avec maven 2, De l'art du livrable et Retour sur la mise en œuvre d'un environnement de développement). Ici, je vais revenir sur le plugin release en version 2.0 en explicitant ce que font ses goals prepare et perform plus concrètement.

En effet, il peut être utile de vouloir savoir quels sont les actions appelées et comment il est possible d'y ajouter son petit grain de sel… ;–)

Il est à noter que je ne reviendrai pas sur l'intérêt d'utiliser un tel plugin (ce n'est pas le sujet qui m'intéresse ici et d'autres blogs ou livres le feront mieux que moi) même si je ferai un petite piqure de rappel sur ce qu'il permet.

in java, maven Read on →

JRebel Ou Comment Accélérer Le Développement

left-small

Dans des posts précédents (ici et ), j'avais parlé d'une façon d'utiliser maven 2 pour fournir, entre autre, une solution pour accélérer le déploiement d'applications web avec Cargo. Cependant, afin d'optimiser le temps de développement, il est préférable, plutôt que d'avoir à redéployer l'application web à chaque modification de son contenu (que ce soit sa vue, son contrôleur ou son modèle) ou de ses librairies tierces (ce qui est connu pour être un anti-pattern), de n'avoir pas à le faire mais d'avoir plutôt un mécanisme permettant de prendre les modifications à chaud afin de pouvoir tester le plus rapidement possible.

Il existe différentes approches telles que :

  • l'utilisation du plugin WTP d'Eclipse en lançant le conteneur de Servlet ou le serveur d'application directement au sein d'Eclipse,
  • l'utilisation du plugin Sysdeo sous Eclipse pour le conteneur de Servlet Tomcat,

Cependant, aucune de ces solutions ne m'avait convaincu et je continuais à utiliser la bonne vieille ligne de commande.

Jusqu'au jour où j'ai entendu parlé de JRebel… Cette solution, bien que payante, remporte l'unanimité des suffrages dans la communauté open-source en raison de sa simplicité et de sa puissance.

Suite à l'obtention d'une licence gracieusement offerte par ZeroTurnaround lors du 2ième anniversaire du Paris JUG (merci à eux et longue vie aux JUGs!!), je ne pouvais que tester à mon tour…

Cet article va donc donner mon retour d'expérience.

in java, jrebel, maven Read on →

De L'art Du Livrable

left Au cours de certaines missions, je suis arrivé à un constat qui était que le processus de génération d'un livrable était souvent délaissé au profit de l'effort de développement de l'application.

C'est vrai qu'il peut être concevable qu'il ne s'agit que de la dernière étape d'un processus de développement, cependant, avec l'introduction de cycles courts (agilité, …), pouvoir fournir rapidement un livrable de qualité au client est primordial.

Dans un post précédent, j'avais parler de la façon dont j'avais en place maven dans un processus d'usine logicielle. J'y avais également abordé succinctement comment il était possible de générer un livrable.

Ce post présente donc plus précisément comment cela est possible avec maven (je ne reviendrai pas sur le pourquoi car cela me parait évident dans le sens où c'est ce que verra le client final et que, tout le monde le sait, la première impression est très souvent importante – un peu comme lorsque l'on offre un cadeau à quelqu'un, l'emballage à son importance même si, au final, le cadeau est pourri… ;–) – ).

in java, maven Read on →

Retour Sur La Mise en Oeuvre D'un Environnement De Développement

left Cet article présente la mise en œuvre que j'ai appliquée lors de la mise en place d'un environnement de développement devant s'interfacer, dans une démarche pseudo-agile, avec des outils d'intégration continue.

Il présentera, dans un premier temps, le contexte et les problématiques puis, dans un second temps, comment j'ai tenté de répondre à ces problématiques que ce soit d'un point de vue méthodologique que d'un point de vue technique. Bien sûr, les choix et les implémentations utilisés sont discutables, mais c'est aussi pour cela que j'ai créé ce blog (afin de faire partager mon expérience et d'avoir un retour) ;–)

Il ne présentera ni l'utilité des outils d'intégration continue ni celle d'une démarche agile (ce projet ne fonctionnait pas en agile mais mettait en œuvre quelques-unes de ses pratiques) qui sont très bien expliqués sur d'autres sites ou blogs. Enfin, il est à noter que ce projet possédait un existant et que mon rôle n'était pas de remettre en cause les solutions retenues.

in cargo, java, jetspeed, maven Read on →