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

Voila quelques raisons qui m'ont fait choisir netbeans comme mon ide de prédilection :

La gestion des plugins est beaucoup plus intégré

Pas besoin d'aller sur un milliard de sites pour récupérer un plugin. Tout est centralisé!

Le support de Maven est natif

Et oui, par rapport à eclipse, le support des projets maven est natif. Quand vous ouvrez un projet maven, netbeans prend en compte automatiquement la configuration des fichiers pom.xml et substitue maven aux builds ant livrés par défaut.

Une seule gestion du classpath

C'est la ou eclipse pêche.... Dans un vrai projet, il y a plusieurs niveaux de classpath à gérer : le classpath pris en compte dans eclipse et celui de maven. Vu que la majorité des problèmes JAVA est lié à la configuration et la gestion du classpath, ca m'économise pas mal de temps.

C'est roots

Oui, eclipse /wtp est peut être trop intégré pour moi, j'aime assez être proche de la configuration cible ( build maven) et exclure de mes résolutions de pb l'IDE.

Ce qui manque encore

• Pas mal de fonctionnalités d'édition et refactoring où eclipse est encore loin devant. Peut être qu' intellijidea est meilleurs mais bon netbeans est libre et gratuit.
• Un support facelets digne de ce nom
• Un support seam :D
• Une bonne complétion dans les annotations JPA et JSF
• Un support de tous les frameworks JSF dans l'editeur graphique

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