Migration Maven 2 : 3ème épisode : retour d'expériences

Il est vrai que je n'avais pas fait de 3ème épisode concernant ce sujet de migration de maven1 vers maven2.

Voici alors le 3ème épisode de la migration plutôt sous la forme d'un retour d'expérience... tintintin...

La migration a été effectuée sur 2 gros projets J2EE avec des processus de build assez complexe. L'utilisation de maven2 est effective depuis maintenant quelques mois. Voici en vrac quelques remarques par rapport à des ajustements effectués après la migration :

• delta au niveau du contenu des archives j2ee. Les archives j2EE ont tendance à prendre de l'enbonpoint (gestion des dépendances transitives, repository différents) : bien définir les exclusions et scopes.
  
• changement de comportement du build suite à l'apparition d'une nouvelle version du plugin : fixer la version de tous les plugins.
• confusion possible avec les fichiers de conf maven1 : une fois que l'utilisation maven2 est bien intégrée, faire le ménage sur les anciens fichiers de conf maven1 qui "polluent" le gestionnaire de sources.

Maven1 est en train d'être oublié par les équipes de développement, preuve que la migration est un succès.

Retouche photo en ligne : Pixlr

Dans le cadre d'un développement orienté web, si vous avez besoin de faire des petites retouches photos, je vous conseille d'utiliser Pixlr. C'est un bon compromis entre une interface simple et conviviale et un nombre de fonctionnalités déjà assez important (Pixlr prend en charge la gestion des calques par exemple).



Le tout est réalisé en Flash et propose des raccourcis clavier. On oublie même que c'est une interface "web". Il ne faut même pas s'inscrire...

Les virtuoses du photoshop seront surement déçus mais pour un outil gratuit et en ligne, c'est assez surprenant.

Voici l'adresse du site :
http://www.pixlr.com

Causes d'échec de l'Intégration continue

Dans certain cas, aux yeux d'une équipe de développement, l'intégration continue se limite à recevoir un mail quand le "build" de l'application échoue. Le problème est que l'intégration continue ne se limite pas seulement à ça...

Il ne faut pas oublier que l'intégration continue n'est pas qu'un outil mais bien un ensemble de pratiques autour de l'ingénierie logicielle. Dans un de ces articles, Martin Fowler présente les pratiques d'intégration continue sur son site.

Voici quelques causes probables d'échecs sur la mise en place d'une démarche d'intégration continue :

• un manque de connaissances de l'ensemble des pratiques d'intégration continue par l'équipe (y compris les managers).

• une mise en place d'un serveur d'intégration continue au niveau d'une équipe projet sans communiquer, informer sur les bénéfices de ce type de démarche et intégrer les principes de fonctionnement que cette mise en place entraine.

Si la volonté de mettre en place ce type de démarche ne vient pas de l'équipe , il faut alors présenter et communiquer autour de la démarche. Il ne faut pas oublier que ce type de pratique est fait pour les équipes de développements et pour leur permettre de travailler efficacement ensemble.

L'intégration continue est avant une histoire de communication. Cela doit être une culture au niveau du projet. Il faut rendre "fun" la pratique de l'intégration continue!

Supprimer les EJbs par Spring

J'ai procédé chez mon client à la réalisation d'une étude sur la suppression des EJBs Sessions sur un de leur applicatif java.

Pourquoi supprimer les EJBs Sessions?

• Pour simplifier l'architecture logicielle de l'applicatif.
• Pour simplifier la plateforme de développements.
• Pour simplifier le processus de construction de l'application.
• Pour augmenter la productivité des développeurs.
• Pour banaliser l'infrastructure serveur (pas de différenciation serveur métier et serveur présentation).
  

Qu'apportent les Ejbs Sessions au niveau de l'applicatif?

• La possibilité de séparer sur des infrastructures différentes la partie présentation et la partie métier. Cette possibilité n'est plus exploitée du fait de leur volonté de banaliser l'infrastructure serveur.

• La possibilité d'appeler la couche Ejbs ( couche "métier") depuis d'autres applications. Ce choix d'interfaçage n'a pas été retenu et il sera pris en charge par la mise en place de Web Services.

• La gestion des transactions. C'est la problématique intéressante qui reste à traiter... avec Spring évidemment...
  

L'intégration de Spring pour prendre en charge la gestion des transactions est réellement facile. Il existe 2 possibilités :

• de façon déclarative dans le fichier de conf Spring.
• Par annotation.

Après avoir testé les 2, j'ai choisi de le faire par annotations. L'inconvénient est d'être intrusif en rajoutant les annotations "@Transactional" dans le code. En revanche, cela augmente la lisibilité au niveau du code. Dans tous les cas, je crois qu'il n'y a pas de mauvaises façons de faire avec Spring mais dans tous les cas des façons "simplifiantes". Voici le lien vers la documentation de Spring qui m'a aidé concernant la gestion des transactions.

Dans le cadre du projet concerné, l'environnement de développement se base sur un simple serveur web Tomcat alors qu'en production, c'est un serveur d'application JBoss. L'applicatif à aussi la particularité d'utiliser un ensemble de datasources.

J'utilise alors un transaction manager différent selon l'environnement :

• Dans l'environnement de développement avec Tomcat, je ne pouvais pas me servir du transactionManager proposer par Spring (org.springframework.jdbc.datasource.DataSourceTransactionManager) car il ne gère qu'une seule source de données. Un article sur le site javaworld explique comment mettre en place un "ChainedTransactionManager" qui s'appuie ensuite sur le transactionManager de spring et permet de gérer plusieurs datasources. Voici un extrait de conf spring correspondante :
  

   <!-- aop pour la gestion des transactions -->
  <tx:annotation-driven transaction-manager="txManager" />
  
  <!-- recuperation des datasources en jndi -->
  <jee:jndi-lookup id="datasource1" jndi-name="jdbc/ds1" />
  <jee:jndi-lookup id="datasource2" jndi-name="jdbc/ds2" />
  <jee:jndi-lookup id="datasource3" jndi-name="jdbc/ds3" />
  <jee:jndi-lookup id="datasource4" jndi-name="jdbc/ds4" />
  
  <!-- declaration du transaction manager -->
  <bean name="txManager" id="txManager" class="com.springsource.open.db.ChainedTransactionManager">
  <property name="transactionManagers">
  <list>
   <bean class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
    <property name="dataSource" ref="datasource1" />
   </bean>
   <bean class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
    <property name="dataSource" ref="datasource2" />
   </bean>
   <bean class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
    <property name="dataSource" ref="datasource3" />
   </bean>
   <bean class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
    <property name="dataSource" ref="datasource4" />
   </bean>
  </list>
  </property>
  </bean>

• Dans l'environnement de production avec Jboss, pas de soucis, j'utilise le transaction manager JTA de spring (org.springframework.transaction.jta.JtaTransactionManager). Voici l'extrait de la conf Spring correspondante :
  

   <!-- transaction manager JTA -->
  <bean name="txManager" class="org.springframework.transaction.jta.JtaTransactionManager" />
  
  
  <!-- aop pour la gestion des transactions -->
  <tx:annotation-driven transaction-manager="txManager" />

  
  

Maven et les dépendances transitives

Une des évolutions de maven2 par rapport à maven1 concerne la gestion de dépendances transitives : La définition d'une dépendance au niveau d'un projet entraîne la récupération des dépendances de cette dépendance et ainsi de suite...

Sur de gros projets, la gestion des dépendances avec Maven est quasiment indispensable. J'ai même dû mal à comprendre qu'on puisse faire sans.

Avec les dépendances transitives, on se retrouve vite à récupérer la terre entière et à avoir des dépendances qui utilisent des dépendances transitives communes mais dans des versions différentes...

On voit apparaître des exceptions du type "NoClassDefFoundError" à l'exécution et c'est là que le casse tête commence...

Voici ce que j'utilise pour résoudre ce genre de problème :

• la commande du plugin maven "dependency" pour découvrir les dépendances en double :
  

  mvn dependency:tree

• La mise en place de tags d'exclusion au niveau des pom.xml pour permettre de définir une dépendance mais d'exclure certaines de ces dépendances transitives :
  

  <dependency>
   <groupId>yourDependencyGroupId</groupId>
   <artifactId>yourDependencyArtifactId</artifactId>
   <version>yourDependencyVersion</version>
   <exclusions>
     <exclusion>
       <groupId>ExcludedTransitiveDependencyGroupId</groupId>
       <artifactId>ExcludedTransitiveDependencyArtifactId</artifactId>
     </exclusion>
   </exclusions>
  </dependency>