maven

Il y a quelques temps, j’avais fait une série d’articles sur resteasy-netty et resteasy-netty4. Cette article repart du même besoin, à savoir disposer d’une stack légère pour réaliser un service REST, mais en utilisant Undertow plutôt que Resteasy-Netty. Au niveau des besoins, ils seront identiques ie. : utiliser JAX-RS, intégrer Swagger, intégrer Jolokia, générer un livrable autoporteur. RestEasy-Netty, même s’il existe de nombreux points d’entrée, demande quelques phases de hack (gestion du crossover domain par exemple) et dispose d’un mécanisme un peu limité concernant la partie sécurité.

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.

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.

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.

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é.

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).

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?

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.

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 : Olivier Lamy (http://olamy.

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.

Ci-dessous se trouve une présentation que j’ai donné sur un retour d’expérience sur Maven 2. Enjoy et n’hésitez pas à commenter ;-) Présentation sur Maven 2 et petit retour d'expérience View more presentations from jetoile

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.

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.

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… ;-)

Dans des posts précédents (ici et là), 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.

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.

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) ;-)