Qu'est ce qu'on se fait ch ... !

Il arrive - je vous demande un maximum d'imagination - que vous ayez échoué la première exécution de la commande mvn release:prepare et que même après avoir lancé un mvn release:clean, les fichiers pom.xml soient vérolés et n'indiquent pas la bonne version du projet exemple :

<version>2.0.1</version>

et non

<version>2.0.1-SNAPSHOT</version>

Pour rétablir, soit vous le faites à la main dans tous les fichiers. Dans le cas d'un projet JAVA EE, ca peut s'avérer fastidieux ou le faire avec PERL Voici la ligne de commande

 $ find . -name "pom.xml" -exec perl -p -i.old -e "s/2.0.1/2.0.1-SNAPSHOT/g" {}\;

En espérant que ca aidera quelques développeurs malchanceux dans leur versions du vendredi soir !

Dans la série, j'essaye d' intégrer tout et n'importe quoi ensemble.... J'ai un projet java ee sous BEA Weblogic. Ce dernier est JAVA EE 5. Il y a tout ce qu'il existe de plus chatoyant : ejb3, jsf, jpa. Pour ce dernier, le provider par défaut est kodo (bon la c'est moins drôle). Bien évidemment, j'ai plus ou moins réussi à maveniser le tout. Pour la réalisation du site, voici le problème:

Cobertura instrumente via un agent les classes après compilation. Kodo essaye à l'exécution d'instrumenter ces mêmes classes. ---> fatal error.

Voila la manipulation que j'ai réalisé avec l'aide du modérateur de la section java de developpez.com

Exclusion des pojo à l'instrumentation de cobertura

Comme d'habitude, il faut savoir lire la documentation ....

<project>
  ...
  <build>
    ...
    <plugins>
      ...
      <plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>cobertura-maven-plugin</artifactId>
        <configuration>
          <instrumentation>
            <ignores>
              <ignore>com.example.boringcode.*</ignore>
            </ignores>
            <excludes>
              <exclude>com/example/couchejpa/**/*.class</exclude>
              <exclude>com/example/**/*Test.class</exclude>
            </excludes>
          </instrumentation>
        </configuration>
        <executions>
          <execution>
            <goals>
              <goal>clean</goal>
            </goals>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>
</project>

Passage de l'agent openjpa/kodo a surefire

 <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-surefire-plugin</artifactId>
        <configuration>
          <forkMode>pertest</forkMode>
          <argLine>-javaagent:D:/kodo-4.1.2/lib/openjpa.jar</argLine>
        </configuration>
      </plugin>

Après vous pourrez vérifier la couverture de tests dans les couches session ( EJB3 SESSION STATELESS et STATEFUL )

Au démarrage d'un projet, il y a toujours cette tâche fastidieuse : initialiser le projet avec tous les composants choisis par l'architecte, la configuration initiale et le tout prêt à développer et à déployer sur le serveur cible.

Maven propose une solution: les archetypes. Le plugin archetype fournit un ensemble de scripts Velocity permettant de créer rapidement un squelette de projet. Il existe déjà quelques archetypes de projet On pourra y retrouver des exemples de projets J2EE, des portlets. Malheureusement, si on veut faire des projets un peu complexes ou représentant un réel développement en entreprise ( ou les deux ), on a besoin de mettre les mains dans le cambouis.

Création de l'archetype

Définition d'un projet exemple.

Sous eclipse ou netbeans , vim pour les puristes , j'ai crée un projet JAVA EE qui me parait cohérent et évolutif. Je le paramètre pour qu'il ait une configuration mavenisée et hop j'ai mon projet démo

├───ears
│   └───ear
│       ├───.settings
│       └───src
│           └───main
│               └───application
│                   ├───APP-INF
│                   │   ├───classes
│                   │   └───lib
│                   └───META-INF
├───ejbs
│   └───ejb
│       ├───.settings
│       ├───build
│       │   └───classes
│       │       └───META-INF
│       └───src
│           ├───main
│           │   ├───java
│           │   └───resources
│           │       └───META-INF
│           └───test
│               └───resources
│                   └───META-INF
└───guis
    └───front-gui
        ├───.apt_src
        ├───.settings
        ├───build
        │   ├───classes
        │   └───weboutput
        │       └───WEB-INF
        └───src
            └───main
                ├───java
                ├───resources
                │   └───resources
                └───webapp
                    ├───META-INF
                    └───WEB-INF
                        ├───classes
                        ├───config
                        └───lib

Les répertoires .settings contiennent les configuration WTP ou BEA WORKSHOP. Il peut être utile de les mettre dans le template afin d'automatiser la configuration initiale.

Initialisation

Comme l'indique le maven book, j'ai crée le squelette de mon archetype avec .... un archetype

mvn archetype:create -DarchetypeGroupId=org.apache.maven.archetypes \
                     -DarchetypeArtifactId=maven-archetype-archetype \
                     -DarchetypeVersion=1.0 \
                     -DgroupId=com.mycompany \
                     -DartifactId=my-archetype

Création du squelette

Dans le répertoire /src/main/resources/archetype-resource, je met les sources de mon projet démo. J'ai inséré dans les différents fichiers les paramètres nécessaires à la création du squelette:

Dans les fichiers pom.xml :

• GroupId
• ArtifactId
• version

Voici un exemple de fichier pom.xml avec les paramètres velocity :

<project>
	<modelVersion>4.0.0</modelVersion>
	<groupId>${groupId}</groupId>
	<version>${version}</version>
	<artifactId>${artifactId}-parent</artifactId>
	<packaging>pom</packaging>
	<name>${artifactId} project</name>
	<description>Parent Project for ${groupId} / ${artifactId} </description>
	  ....

Je crois que le système est extensible. Vous pouvez rajouter des propriétés à l'execution qui seront automatiquement résolues à la création du squelette.

Paramétrage et définition des meta données

Dans le fichier pom.xml racine ( celui de l'archetype ), mettre les références de l'archetype

Exemple :

<project>
  <modelVersion>4.0.0</modelVersion>
  <groupId>mon.groupe</groupId>
  <artifactId>mon-archetype</artifactId>
  <version>1.0-SNAPSHOT</version>
  <packaging>maven-plugin</packaging>
</project>

Dans le fichier /src/main/resources/META-INF/maven/archetype.xml indiquer les fichiers à prendre en compte dans le squelette

Exemple :

<archetype>
    <id>mon-archetype</id>
    <resources>
		<!-- Niveau Parent -->
        <resource>pom.xml</resource>
		<!-- Niveau EAR -->
        <resource>ears/pom.xml</resource>
		<resource>ears/ear/pom.xml</resource>
		<resources>ears/ear/.project</resources>
		<resources>ears/ear/.settings/org.eclipse.wst.common.component</resources>
		<resources>ears/ear/.settings/org.eclipse.wst.common.project.facet.core.xml </resources>
		<!-- Niveau WAR -->
		<resource>guis/pom.xml</resource>
		<resource>guis/front-gui/pom.xml</resource>
                  [...]
		<!-- Niveau EJB -->
		<resource>ejbs/pom.xml</resource>
		<resource>ejbs/ejb/pom.xml</resource>
                 [...]
    </resources>
    <sources>
    </sources>
	<allowPartial>true</allowPartial>
</archetype>

Installation et déploiement

A la racine de l'archetype, entrez la commande suivante dans un prompt:

$mvn install 
$mvn deploy

Création du squelette

Dans un répertoire , lancer la commande

$ mvn  archetype:create -DarchetypeGroupId=mon.groupe -DarchetypeArtifactId=
mon-archetype -DarchetypeVersion=1.0-SNAPSHOT -DgroupId=test.package -Dartifac
tId=testprojet -Dversion=12345

Et la, oh miracle de la technologie moderne, on a un beau projet tout beau