Rappel : qu’est-ce qu’un ORM ?

Un ORM fonctionne sur la base d’ajout de méta-données décrivant une correspondances entre des tables et colonnes de base de données et des objets et leurs propriétés.

Concrètement, un utilisateur pourra être modélisé par une classe

public class User

{
private int id;
private String nom;
private String prenom;
// Getters et setters
}

Les méta-données pouvant ressembler globalement à ça :

<mapping>

<class name="User" table="USER_TABLE">

<property name="id" column="USER_ID" />

<property name="nom" column="USER_LASTNAME" />

<property name="prenom" column="USER_FIRSTNAME" />

</class>

</mapping>

Attention à ne pas considérer cet exemple comme fonctionnel il permet uniquement de se faire une idée du principe.

Une fois cette configuration effectuée, vous pouvez ensuite travailler avec un gestionnaire d’entité qui prendra automatiquement en charge la persistance de votre objet au sein de la base de données que vous utilisez.

Concrètement, ce gestionnaire d’entité travaille avec un pool d’objets, souvent appelé «cache de premier niveau», qui contient des objets récupérés de la base de données. Il propose pour cela des fonctions type :

• save
• queryForObject
• queryForList
• merge
• …

pour sauvegarder / récupérer des éléments dont le mapping a été défini, ou intégrer des objets au cache de premier niveau.

L’autre fonctionnalité très prisée d’un ORM concerne la modélisation des relations entre les objets et donc les tables. Vous pouvez effectivement indiquer que votre utilisateur dispose de profils et ce profil de rôles.

Vous aboutirez à un modèle de type :

Il est alors possible de modéliser ces relations dans les méta-données et déclarer des propriétés supplémentaires dans notre classe. Par exemple, la classe User se verra ajouter

private List<Profile> profiles;

avec ses getter / setter associés.

Grâce au mécanisme de l’ORM, l’appel au getter getProfiles() d’une instance de la classe user récupérée via le gestionnaire d’entité provoquera une requête SQL de type :

SELECT p.*

FROM PROFILE_TABLE p, USER_PROFILES up

WHERE up.PROFILE_CODE = p.PROFILE_CODE AND up.USER_ID = ?

le résultat de cette requête permettant de créer la liste d’objets Profile dont je vous laisse imaginer le code.

Les frameworks ORM

Le framework Java le plus connu sur ce sujet est Hibernate, qui a notamment introduit ce concept (ou l’a du moins fait connaître), repris ensuite officiellement par la communauté Java sous le doux nom de JPA (Java Persistence Annotations). JPA permet notamment de définir les méta-données par l’intermédiaire d’annotations Java de type @Column, @Table, etc. …

.NET a vu un portage d’Hibernate appelé NHibernate, lancé dans le cadre de la «dotnetification» des frameworks Java (log4j devient log4net, JUnit devient NUnit…). Pourtant la solution de DataSet .NET offrait déjà des fonctionnalités assez proches, et particulièrement bien intégrées à l’environnement de développement, mais j’imagine que cette opération a eu le mérite de permettre aux habitués du framework à transiter vers .NET de manière plus rapide et fluide. A noter, vu qu’on parle de .NET que depuis la version 3, on a vu apparaître le framework LINQ, avec notamment LINQ to SQL qui se place en concurrent officiel de NHibernate, avec un périmètre bien plus large, notamment sur sa capacité à travailler sur les collections en mémoire à l’aide de prédicats proches du SQL. Pour le coup, et malgré un plugin Hibernate Tools proposé par JBoss sur Java, la solution Microsoft se montre particulièrement bien pensée au niveau de son intégration à l’environnement de développement (ce qu’on comprend parfaitement quand on regarde le prix de Visual Studio en face d’un eclipse gracieusement mis à disposition).

Je passe les portages divers et variés ayant pu voir le jour sur d’autres plateformes, n’ayant pas le recul nécessaire, mais je suis certains qu’il en existe.

Le constat

Après avoir pris le temps de comprendre le fonctionnement d’un ORM en l’utilisant sur des projets existants ou en tentant de le mettre en place sur des projets partant d’un développement «from scratch», je me suis heurté aux problèmes liés à la persistance et à ce fameux cache de premier niveau. En effet, travailler avec deux versions d’un même objet, l’un existant dans le cache et l’autre non (créé par exemple à l’issue d’une soumission de formulaire, peut facilement poser des problèmes de cohérence, et demandent qu’on tienne compte des particularités du concept d’ORM pour que les exceptions StaleObjectException ou LazyInitializationException soient gérées correctement (ou peut-être devrais-je dire «tant bien que mal»).

Et c’est là que le bât blesse : l’ORM, bien que simplifiant la gestion des accès à une base de données peut très facilement être une source de problèmes de performances ou de stabilité d’une application s’il n’est pas utilisé à bon escient, ou par une personne non encadrée d’un expert du domaine.

Imaginez que l’on cherche à parcourir la liste des rôles d’un utilisateur récupéré au moyen d’un ORM dans notre exemple de tout à l’heure :

Iterator<Profile> profilesIter = user.getProfiles().iterator();

while (profilesIter.hasNext())

{

Profile currentProfile = profilesIter.next();

Iterator<Roles> rolesIter = currentProfile.getRoles().iterator();

while (rolesIter.hasNext())

{

Role currentRole = rolesIter.next();

// Faire quelque chose

}

}

En pratique, il est tout à fait probable que ce code, presque indolore sur des collections d’objets présents en mémoire, se traduise avec un ORM par une série de requêtes SQL. En considérant que ce code serve à contrôler qu’un utilisateur dispose d’un rôle donné au sein d’une application – étant donc appelé très souvent pour chaque utilisateur de l’application – on peut tout à fait imaginer les problèmes de performances posés.

« C’est un problème de paramétrage »

Effectivement, ces problèmes sont souvent liés à la méconnaissance du framework et à des problèmes de paramétrage. Je ne suis moi-même pas expert Hibernate mais le connais assez pour savoir qu’un bon paramétrage peut faire toute la différence et que le code d’une application doit également se conformer au paradigme d’ORM.

J’ai aussi tendance à considérer ce type de travail comme un luxe. En effet, à niveau équivalent, un développeur sera capable de produire une requête SQL relativement efficace alors qu’il restera incapable de proposer un paramétrage Hibernate adéquat.

En conclusion, bien manipulé, l’ORM peut être très intéressant et apporter en lisibilité de code. A l’inverse, mal utilisé, il pose plus de problèmes qu’il n’est sensé en résoudre (performances, «hacks» divers et variés…).

Les alternatives

Et si je ne veux pas d’ORM sur mon projet ? C’est une question à se poser : les problèmes posés par un ORM, selon l’organisation et l’expérience de l’équipe de développement, peuvent être un frein à la réussite d’un projet.

Vous pouvez globalement recourir à :

• Un «mappeur de requêtes SQL» permettant d’exécuter des requêtes rédigées par vos soins, et automatiquement «mappées» sur des objets selon la configuration mise en place. Un framework Java assez connu dans ce domaine est iBatis (repris récemment sous le nom MyBatis) qui donne des résultats tout à fait satisfaisants, notamment par rapport à sa facilité de mise en oeuvre et sa proximité de fonctionnement avec des appels standards JDBC.
• Des appels JDBC natifs «bruts» qui manquent de classes facilitant les appels et traitements des résultats. En le complétant du framework Spring et son JdbcTemplate, vous obtenez une solution très simple à mettre en place et aisément compréhensible par une équipe de développement peu expérimentée.

Que choisir ?

Aujourd’hui, selon le contexte de la société dans laquelle un projet donné est réalisé, deux grandes catégories d’équipe se distinguent :

1. Une équipe composée de profils similaires, évoluant ensemble sur les développements applicatifs de la société pour laquelle ils travaillent.
2. Une équipe encadrée par un senior et composée de profils juniors.

Dans le premier cas de figure, la capitalisation sur la technologie sera généralement pérenne, l’équipe restant stable et organisée autour d’un socle applicatif donné. Dans ce cadre, les problèmes liés à l’utilisation d’un ORM ne se posent finalement qu’au démarrage et sont gommés par la suite.

Dans la seconde configuration, le cadrage est fait par l’architecte de manière globale, mais souvent difficilement appliqué à tous les aspects du développement. Concrètement, l’expert interviendra à la demande d’un junior coincé sur un problème, et règlera le problème avec lui en tentant de lui apporter les connaissances manquantes. Dans ce schéma, à force, les juniors intégreront les concepts et deviendront seniors à leur tour, encadrant d’autres juniors et l’histoire se répètera.

Conclusions

Vous aurez compris que je ne suis personnellement pas friand d’ORM, lui préférant des solutions plus simples, ayant trop souvent eu à gérer des problèmes liés à l’incompréhension du framework, des tentatives de paramétrage a posteriori pour contrer les problèmes de performances… Mais tout dépend de votre configuration d’équipe, cela reste un choix très intéressant dès lorsque qu’il est partagé et que chaque membre de l’équipe maîtrise les tenants et aboutissants de cette technologie.

Et vous, vous êtes ORM ?Autres articles sur le même sujet

• Vous avez dis Flex3 Beta2 ?
• Quicksilver, non-action et Tao appliqués à MacOS X [@Google Talks]
• MAX 2009 – JPA, BlazeDS et LiveCycle DS
• AIR 2 : appeler un JAR exécutable via un NativeProcess

Fonctionnement et limites d’un NativeProcess

Packaging de l’application

Pour diverses raisons de sécurité, une application AIR utilisant un NativeProcess doit être packagée dans le format de la plateforme cible (exe pour Windows, dmg pour Mac, rpm / deb / … pour Linux). Fini donc dans ce cas le pratique fichier .air qui marche partout !
Vous devez également indiquer dans le descripteur de l’application qu’il s’agit d’une application au profil « extendedDesktop » lui conférant donc les capacités d’exécuter un NativeProcess.
Vous devez ouvrir le fichier monAppli-app.xml et modifier la balise <supportedProfiles>

<supportedProfiles>extendedDesktop</supportedProfiles>

A partir de là, si vous tentez d’exporter un fichier .air, vous aurez un joli message d’erreur vous invitant à changer de profil.

Considérations de sécurité

Si AIR sans native process dispose de limitations de sécurité, dès lors que vous utilisez un native process, vous ouvrez la porte… Il est donc bon d’anticiper et de faire un maximum de vérifications sur vos appels pour éviter un remplacement d’un exécutable par un autre, moins sympathique, par exemple…

Prêt ? On code

Paramétrage

Un native process a besoin d’un contexte d’exécution. Ce contexte est défini à l’aide de l’objet NativeProcessStartupInfo décrivant notamment les éléments suivants :

• workingDirectory : le répertoire d’exécution
• executableFile : l’exécutable à lancer
• arguments : la liste des arguments à passer à l’exécutable (Vector.<String> sous Flash Player 10, ou un bête Array sinon)

Vous pourrez alors instancier un objet NativeProcess et lui passer cet objet de paramétrage avant de le lancer.

Lancement & suivi de l’exécution

Le lancement d’un NativeProcess est asynchrone. Il propose donc un certain nombre d’événements vous permettant de suivre son exécution une fois lancé, notamment :

• ProgressEvent.STANDARD_OUTPUT_DATA : écriture sur la sortie standard
• ProgressEvent.STANDARD_ERROR_DATA : écriture sur la sortie d’erreur
• IOErrorEvent.STANDARD_OUTPUT_IO_ERROR : déclenché lorsqu’une erreur apparaît en tentant de lire la sortie standard
• IOErrorEvent.STANDARD_ERROR_IO_ERROR : déclenché lorsqu’une erreur apparaît en tentant de lire la sortie d’erreur
• NativeProcessExitEvent.EXIT : déclenché lors que l’exécution du process est terminée

Lecture de l’entrée / sortie standard

Bien que tout à fait possible, la lecture de la sortie standard ou d’erreur via le listener ProgressEvent.STANDARD_OUTPUT_DATA ou ProgressEvent.STANDARD_ERROR_DATA n’est pas fiable à 100% concernant le contenu retourné : la sortie étant « bufferisée », vous n’aurez donc pas systématiquement le même résultat selon la machine exécutant le programme, à chaque appel de votre listener… N’utilisez donc la lecture de sortie standard que pour afficher ce qui se passe, ou à la limite récupérer la totalité du contenu écrit une fois le process terminé…

Appeler un JAR

Rappels

Pour appeler un JAR en Java, il doit être exécutable (bah oui…), et appelé en ligne de commande de la manière suivante :

java -jar monJar.jar [-cp jars du classpath]

Nous sommes dans une appli AIR, donc évitons de surcharger la commande à appeler avec un classpath, aussi je vous suggère d’utiliser les fonctionnalités d’export complets d’un JAR (si les licences associées vous l’autorisent) intégrant au final l’ensemble des sources dans un groooos JAR contenant tout ce qu’il lui faut pour fonctionner.
Notes :

• Les utilisateurs de Maven peuvent utiliser le plugin qui va bien pour ça.
• L’export eclipse, c’est pas mal non plus, il suffit de cocher la « case qui va bien » au moment d’exporter

Depuis un NativeProcess

On voit mieux ce qui se dessine:

1. Définir l’exécutable java dans vos « startup infos »
2. Définir les arguments
   • -jar
   • /chemin/vers/monJar.jar
3. Ajouter les listeners permettant de savoir lorsque l’exécution est terminée
4. Lancer le native process

Restons multi plateforme

Java est multi plateforme, oui, mais l’exécutable dépend de la plateforme, aussi il vous faudra récupérer le chemin vers votre JAVA_HOME (contenant le répertoire bin avec l’exécutable Java).
Vous avez donc deux solutions maintenant:

1. La plus simple (pour le développeur) : demander à votre gentil utilisateur où est son JAVA_HOME. Ça peut le faire si c’est un geek velu qui a compris qu’on ne parlait pas de venir danser chez lui (aïe, elle est rude celle-ci)
2. La plus compliquée (mais pratique pour l’utilisateur) : utiliser un autre exécutable (voire NativeProcess) qui remonte cette information ou permette de pointer directement sur l’exécutable en question

La seconde solution bien que séduisante est un peu plus longue à implémenter.
Pour les développeurs sous Windows, j’ai noté l’utilisation par Serge Jespers d’un petit (mais pratique) exécutable « jexe.exe » lançant le java.exe présent dans le %JAVA_HOME%\bin de la machine. L’utiliser vous évitera la première solution, sans vous lancer dans un développement spécifiquement dédié à cela (merci Serge). En revanche, si votre application est diffusée à un public d’utilisateurs non avertis, ils sont tout à fait susceptibles de ne pas avoir de variable JAVA_HOME définie sur leur machine : pensez donc à déterminer précisément votre cible avant de choisir une solution.

J’ai également noté en relisant un extrait de la licence du JRE que la redistribution est autorisée sous certaines conditions. Si vous les remplissez, vous pourriez carrément embarquer le runtime java dans votre application AIR, au risque de la faire gonfler en taille…

Un exemple ! Un exemple !

Voici un petit exemple de code permettant de lancer un JAR exécutable depuis une application AIR :

package com.lafabrick.nativeprocess
{
import flash.desktop.NativeProcess;
import flash.desktop.NativeProcessStartupInfo;
import flash.events.EventDispatcher;
import flash.events.NativeProcessExitEvent;
import flash.events.ProgressEvent;
import flash.filesystem.File;
import flash.system.Capabilities;

public class JarExec
{
protected var _process:NativeProcess;

public function JarExec()
{
}

public function getDefaultJavaExecutable():File
{
if (Capabilities.os.toLowerCase().indexOf("win") > -1)
{
return File.applicationDirectory.resolvePath("native/jexe.exe");
}
if (Capabilities.os.toLowerCase().indexOf("mac") > -1)
{
// TODO: Changer avec un paramètre de configuration
return new File("/System/Library/Frameworks/JavaVM.framework/Commands/java");
}
throw new Error("Système non pris en charge");
return null;
}

public function testJava(executablePath:String = null):void
{
// Tester le lancement de l'exécutable 'java'
try
{
var nativeProcessStartupInfo:NativeProcessStartupInfo = new NativeProcessStartupInfo();
nativeProcessStartupInfo.workingDirectory = File.applicationDirectory;
nativeProcessStartupInfo.executable = (executablePath == null ? getDefaultJavaExecutable() : new File(executablePath));

var args:Vector.<String> = new Vector.<String>();
args.push("-version");
nativeProcessStartupInfo.arguments = args;

_process = new NativeProcess();
_process.addEventListener(NativeProcessExitEvent.EXIT, onJavaTestExit);
_process.addEventListener(ProgressEvent.STANDARD_OUTPUT_DATA, onStandardOut);
_process.addEventListener(ProgressEvent.STANDARD_ERROR_DATA, onErrorOut);
_process.start(nativeProcessStartupInfo);

trace("-- Début d'exécution");
}
catch (e:Error)
{
trace("Impossible de lancer le process\n" + e.message + "\n" + e.getStackTrace());
}
}
protected function onStandardOut(e:ProgressEvent):void
{
trace("STDOUT: " + _process.standardOutput.readUTFBytes(_process.standardOutput.bytesAvailable));
}
protected function onErrorOut(e:ProgressEvent):void
{
trace("STDERR: " + _process.standardError.readUTFBytes(_process.standardError.bytesAvailable));
}
protected function onJavaTestExit(e:NativeProcessExitEvent):void
{
trace("-- Fin d'exécution");
}
}
}

Cet extrait donne un aperçu, mais vous pouvez vous lancer (soyons fous) à installer le package suivant :

Pour Mac

Pour Windows

Pensez au clic droit > View Source…

Packager l’application

Comme je le disais au début de ce post, il est nécessaire de packager votre application dans le format natif du système d’exploitation visé. Vous avez deux solutions pour cela :

1. Passer par la dernière version de Flash Builder 4 qui propose cette fonctionnalité
2. Utiliser l’application PackageAssistantPro proposée par Serge Jespers (re merci Serge)

Il s’agit d’une application AIR utilisant des NativeProcess (et packagée en ligne de commande vu que l’application n’existait pas avant… Remarquez, la version 2 et plus ont probablement été packagées avec la version 1… Mais je m’égare)

Quelques liens

• Un petit exemple d’application utilisant un NativeProcess : ZXPackager
• ASDoc de la classe NativeProcess [EN]
• Un bon article pour démarrer [EN]

Autres articles sur le même sujet

• Un projet Java / Flex avec Maven 2
• Arduino #2 : Flash, socket et Processing
• ZXPackager : application pour l’empaquetage ZXP d’extensions CS5
• RollingFileTarget pour AIR 2.0 : let’s roll !

Aoutch ! Rien que le titre fait un peu peur. L’idée de cette conférence est de présenter le framework JPA (Java Persistence API) et son utilisation dans le cadre d’un projet Flex avec BlazeDS ou LiveCycle Data Services.

Oui, c’est velu, mais ça passe.

A savoir que je n’ai pas assisté à la totalité de la conférence, pour pouvoir rencontrer plus de personnes sur les stands.

Que les non techniciens s’arrêtent ici, et ne cliquent pas sur « Lire la suite » sous peine de maux de tête.

JPA / Hibernate

JPA

Il s’agit d’un framework permettant de concevoir sa base de données à partir de POJOs Java, auxquels sont ajoutés des annotations JPA. Ces annotations permettent de définir un modèle de données sous-jacent, qui pourra par la suite être créé physiquement sur la base de données de votre choix à l’aide d’une tâche Ant.

J’ai bien aimé leur anecdote : ils sont trois développeurs, et utilisent tous les trois des IDE différents et des bases de données différentes, mais comme ils ont JPA et que ce dernier permet de regénérer la base de données via Ant et ce quelque soit le SGBD cible, ils s’en foutent (oui, ils sont fous ces types).

Si vous n’avez rien compris, allez sur lequipe.fr, ça sera sûrement plus productif.

Hibernate

Il faut savoir ensuite que JPA reste une API, et qui dit API dit interface, aussi est-il nécessaire d’y adjoindre une implémentation. C’est ici qu’hibernate intervient. Concrètement, en définissant votre modèle de données avec JPA, vous pourrez utiliser Hibernate comme exécutant et vous permette d’interroger votre base de données. Le gros intérêt ici, c’est que JPA vous offre la possibilité de vous affranchir d’une configuration supplémentaire à l’aide des fameux fichiers HBM au format XML, les annotations JPA décrivant déjà cette information.

Pour le reste, les classes de votre couche prenant en charge l’accès aux données utiliseront Hibernate comme avant (je suis sûr que vous utilisiez déjà Hibernate avant, mais si).

J’avais prévenu, JPA, ça pique surtout quand il arrive avec son pote Hibernate.

Spring et BlazeDS

Comme on s’ennuyait un peu et qu’il n’y avait pas assez de frameworks, on embraye sur l’utilisation de Spring et BlazeDS.

Les conférenciers nous présentent comment utiliser Spring pour configurer les canaux de discussion entre Flex et les services Java (i.e. le message broker). Pour le coup, je connaissais déjà, mais un petit rappel sur le sujet est bon à donner compte tenu de la simplification apportée dans la configuration (si tant est qu’on utilise Spring) à l’aide de spring-flex.

Concrètement il suffit de déclarer dans la configuration XML Spring des beans avec le namespace flex: pour déclarer les destinations que vous pourrez ensuite utiliser avec un RemoteObject Flex.

On peut donc mapper des services Java via Spring comme ça :

C’est bien pratique quand on sait ce qu’il fallait faire avant pour dire à BlazeDS d’utiliser un bean Spring comme service.

LiveCycle DS

La conférence commençant à tourner court, et le sujet étant principalement les avantages de LiveCycle Data Services par rapport à BlazeDS, j’ai quitté la salle. J’avoue également que le dynamisme n’était pas particulièrement au rendez-vous (on ne peut pas être un super velu et un gai luron en même temps il faut croire, parce qu’ils étaient vraiment, vraiment super velus).

Je vous laisserai donc consulter le web pour connaître ces différences, qui seront certainement mieux couvertes par un article consacré, mais ce que j’ai retenu avant de partir : possibilité d’utiliser RTMP, lazy loading.

Conclusion

J’ai eu un aperçu assez clair de JPA et de son intérêt : développer son modèle de données sous forme de classes Java et ne pas se soucier plus que ça de la base de données si ce n’est lors de la définition des annotations. Intéressant : pour une fois qu’un framework comme cela ne nécessite pas plus de configuration que cela et permet même d’en supprimer, c’est bien !

Enfin, peu voire pas de techno Flex dans cette conférence… Peut-être était-ce le lot de consolation pour les purs développeurs Java assistant à MAX ? Dommage.Autres articles sur le même sujet

• Un projet Java / Flex avec Maven 2
• Reflex #2 : vous reprendrez bien un peu de IOC ?
• AIR 2 : appeler un JAR exécutable via un NativeProcess
• ORM, Hibernate et contrariétés…

Comment personnaliser un peu la compilation Flex pour l’adapter à mes besoins ?

C’est par là…

Introduction

Si vous êtes ici, c’est donc que vous disposez :

• d’un fichier start.cmd qui vous permet de lancer une ligne de commande permettant l’usage de Maven avec Flex
• d’un projet Flex de test, constructible via Maven 2 et donc de son fichier pom.xml

Ce que nous allons faire

L’objectif est simple, une application Flex ne venant jamais seule, il devient rapidement intéressant de non seulement construire son SWF, mais également de préparer son WAR. Dans ces cas là, il devient intéressant de pouvoir effectuer ces tâches en une seule fois.

En pratique

Maven offre une possibilité très intéressante : le POM parent. Il s’agit en fait d’un « Meta POM » décrivant un ensemble de modules d’un projet plus global. Vous l’avez compris, votre projet global est une application Java / Flex, vos modules sont :

• L’application Flex d’un côté
• La webapp Java de l’autre

De ce fait, nous allons avoir trois fichiers pom.xml :

1. Le POM parent décrivant le projet global (le fameux Meta POM)
2. Le POM du projet Flex
3. Le POM du projet Java

A nos outils

Construction de l’arborescence du projet

Maven propose (encore ?!) un outil très intéressant : les archetype. L’idée est de permettre la construction d’une arborescence type de projet en une ligne de commande.

Si je reprends l’arborescence du toto précédent, vous devez vous positionner dans le répertoire parent de demo-flex, soit, dans l’exemple suivant, au niveau de lafabrick :

Vous pouvez alors exécuter la fameuse ligne de commande : mvn archetype:create -DgroupId=com.lafabrick -Dpackagename=com.lafabrick -DartifactId=demo-java -DarchetypeArtifactId=maven-archetype-webapp

A la suite de cela, vous pouvez constater que l’arborescence suivante a été créée :

Vous constaterez également qu’un fichier pom.xml a été automatiquement créé dans le répertoire demo-java. Ce fichier est un fichier standard décrivant une webapp Java. Il ne reste à présent plus qu’à créer notre Meta POM et a indiquer à nos deux modules qu’ils sont des modules de ce dernier.

Voici le fichier pom.xml à créer au niveau du répertoire lafabrick (cf. arborescence ci-dessus).

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">

<modelVersion>4.0.0</modelVersion>
<groupId>com.lafabrick</groupId>
<artifactId>parent</artifactId>
<packaging>pom</packaging>
<version>1.0</version>
<name>Projet Java Flex avec lafabrick</name>
<url>http://maven.apache.org</url>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
</dependencies>
<modules>
<module>demo-flex</module>
<module>demo-java</module>
</modules>
</project>

Ce Meta POM (oui, j’aime bien cette expression bizarre) est finalement plutôt synthétique : il indique bien nos deux modules demo-java et demo-flex comme faisant partie d’un projet global nommé Projet Java Flex avec lafabrick.

Il reste à présent encore une dernière chose à faire : lier nos module au Meta POM (yes !).

Pour cela, ouvrez les fichiers pom.xml de chacun des projets et ajoutez-y les informations suivantes en tête de fichier (juste après le noeud racine <project>)

<parent>
<groupId>com.lafabrick</groupId>
<artifactId>parent</artifactId>
<version>1.0</version>
</parent>

Testons l’ensemble :

• rendez-vous dans le répertoire lafabrick
• ouvrez votre ligne de commande et tapez mvn clean package

Le résultat : nous avons à présent un fichier demo-flex-1.0.swf dans demo-flex/target et (entre autres) un fichier demo-java.war dans le répertoire demo-java/target.

Mouais, pas mal, mais comment faire en sorte que le résultat de ma compil SWF aille dans ma webapp ? C’est simple, il suffit de modifier la propriété directory de votre projet flex.

Pour cela, modifiez le fichier pom.xml du projet Flex en ajoutant, dans la balise <build>, la ligne suivante :

<directory>${basedir}/../demo-java/src/main/webapp/flex</directory>

Enregistrez et relancez la commande de construction du projet (comme tout à l’heure).

Voilà qui est mieux ! Le résultat est placé dans le répertoire demo-java/src/main/webapp/flex qui est ensuite inclus dans le WAR.

Attention cependant : en manipulant le répertoire de sortie du SWF, maven va, à chaque clean, supprimer la totalité du répertoire concerné, aussi, n’indiquez pas demo-java/src/main/webapp, vous vou retrouveriez à supprimer l’ensemble des sources de la webapp !;

Aller plus loin

BlazeDS ?

Vous pourriez en vouloir un peu plus, notamment concernant les options de compilation de l’application Flex : il est probable que vous ayez à indiquer par exemple le fichier <em>services-config.xml</em> à utiliser dans le cadre de l’utilisation des BlazeDS. Il faut savoir que le plugin ServeBox permet de modifier toutes (ou presque) les options de compilations disponibles avec mxmlc.

Aussi, je peux modifier mon fichier pom.xml le fichier services-config.xml à utiliser :

<build>
<directory>${basedir}/../demo-java/src/main/webapp/flex</directory>
&lt;plugins&gt;
&lt;plugin&gt;
&lt;groupId&gt;org.servebox.flex2&lt;/groupId&gt;
&lt;artifactId&gt;flex2-plugin&lt;/artifactId&gt;
&lt;version&gt;0.9.1&lt;/version&gt;
&lt;extensions&gt;true&lt;/extensions&gt;
&lt;configuration&gt;
&lt;sourceDirectory&gt;/src/main/flex&lt;/sourceDirectory&gt;
&lt;mxmlFile&gt;src/main/flex/Main.mxml&lt;/mxmlFile&gt;
&lt;services&gt;${basedir}/../demo-java/src/main/webapp/WEB-INF/flex/services-config.xml&lt;/services&gt;
&lt;contextroot&gt;demo-java&lt;/contextroot&gt;
&lt;/configuration&gt;
&lt;/plugin&gt;
&lt;/plugins&gt;
&lt;/build&gt;

Et voilà qui est fait.

Les différentes options disponibles pour l’instant…

Après un tour dans les sources du plugin, on retrouve la liste suivante des possibilités de paramétrage :

• home (chemin vers le répertoire du SDK)
  Par défaut, prendra la valeur de la variable d’environnement FLEX_HOME
• config (chemin vers le fichier flex-config.xml du SDK)
  Par défaut : ${flex2.sdk.home}/frameworks/flex-config.xml
• out (répertoire cible de la génération du SWF / SWC)
  Par défaut : le répertoire <directory> indiqué dans la section <build> du POM
• source (répertoire de sources Flex)
  Par défaut : src/main/flex
• optimize (optimisation du bytecode)
  Par défaut : true
• strict (mode strict)
  Par défaut : true
• Xmx (taille de la mémoire en Mo allouée au compilateur)
  Par défaut : 128
• contextroot (nom du contexte de la webapp)
  Par défaut : - vide -
• services (fichier services-config.xml à utiliser)
  Par défaut : - vide -
• useNetwork (utilisation du réseau ou non)
  Par défaut : true
• chartinglicence (votre licence des composants graphiques)
  Par défaut : - vide -
• asencoding (encodage de caractères des sources AS)
  Par défaut : utf-8
• debug (mode debug)
  Par défaut : false
• showbindingwarnings (warning sur les détections de changements de contrôle non pris en compte)
  Par défaut : true
• showaswarnings (warning sur les classes ActionScript)
  Par défaut : true
• showdeprecationwarnings (warning si utilisation de notations dépréciées)
  Par défaut : true
• showtypeselectorwarnings (warning si utilisation <mx:Style>)
  Par défaut : true
• accessible (mode accessible)
  Par défaut : false

Avec ça, si on peut pas faire du Flex avec Maven, c’est que vous utilisez les modules (RSL), et que ce n’est pas encore pris en compte…

A bientôt !Autres articles sur le même sujet

• Installer son environnement de développement : Tomcat – Eclipse – WTP – Flex Builder
• Maven 2 – Flex 2 – une synergie possible ?
• Utiliser Cairngorm dans un projet Flex / AMFPHP
• AIR 2 : appeler un JAR exécutable via un NativeProcess