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 !

This installation guide step by step is based on my needs: I am user of Java and Maven technologies, and Tomcat and JBoss servers. This installation allows you to get all the tools necessary for these types of developments, starting from a “from scratch” Eclipse IDE or a standalone FlashBuilder.

Start !

Need an IDE ! 2 ways : Eclipse and FlashBuilder plug-in, or the standalone distribution of FlashBuilder.

• Link for Eclipse (take the Eclipse Classic distribution)
• Link for FlashBuilder

I use in this guide FlashBuilder, standalone distribution.

FlashBuilder Softwares Updates

Ganymede Softwares Updates Remote site management with « Manages Sites » : you just need to provide the url. The selection of required plug-ins is automatic (be sure you have select all you need in « Manages Sites »)

Subclipse : subversion for Eclipse

Subclipse is an eclipse plug-in which provides support for Subversion (SVN).

To install subclipse :

• open “Help > Softawre Updates > Find and install…” dialog box.
• Choose “Search for new features to Install” and click on “Finish”.
• In the next box, click on “new remote site”. The dialog box for enter an update site appear.
• Type “subclipse” in Name input, and “http://subclipse.tigris.org/update_1.6.x” in the url update address input.
  
• Click on “Ok”.
  Verify in the list of includes sites that subclipse is selected. Select also “Ganymede Discovery Site” (Europa if your are on a Eclipse 3.3 IDE).
  
• Click on “Finish”.
• In the search results box, open the Sublclipse folder, en select “Subclipse”. An error appears. Don’t panic! Some additional plug-in are necessary. Click on “Select Required” button: Eclipse check the list of not found plug-in, and select automatically all required plug-in in Ganymede Discovery Site.
• Click on “Next”. Some validation, and other dialog box appear. Validate all boxes.
• you can also take a coffee… But attention ! A lot of coffee can be taken during this installation.

For PHP developer : PDT !

You know : with eclipse you can make coffee ! Some cool tool exist for Eclipse. If you are a PHP developer, you can use PDT – PHP Development Tool.
PDT, like WTP – See further- add to your Eclipse some tools for developing PHP application.
For more information about PDT, visit the PDT homepage.

To Install PDT, follow these steps :

• In “Help > Softawre Updates > Find and install…” , choose “Search for new features to Install” and click on “Finish”.
• Next, you need to add 2 Remote Site : PDT, and DLTK – Dynamic Language ToolKit.
  Click on “new remote site” :
  • Adding PDT : in Name input, type “PDT”, and for url : “http://download.eclipse.org/tools/pdt/updates/2.0/”
  • Adding DLTK : in Name input, type “DLTK”, and for url : “http://download.eclipse.org/technology/dltk/updates-dev/1.0M4-PDT-2.0/”

  Verify in the list of includes sites that PDT and DLTK are selected. Select also “Ganymede Discovery Site”, and click on “Finish”.

• In the list, select « PDT > PDT SDK 2.0.x > PDT SDK Feature”. An error appear : click on “Select required”. Then, “Next”.
  
• Another coffee?

If your needs is just PHP : Stop ! The following is just for Java developers.

Web Tools Platform : a tribute to Java

Web Tools Platform (WTP) is a package of some tools for your eclipse IDE, which provides you to develop web and J2EE application. WTP add to your IDE the J2EE perspective (a very good view of your code), Some other stuff is added with the WTP. I invite you to discover all this !
For more information about WTP, visit the Webtools homepage.

Installing WTP is like the installation of subclise. More simple.

• Open “Help > Softawre Updates > Find and install…”.
• Choose “Search for new features to Install” and click on “Finish”.
• Select “Ganymede Discovery Site” and click on “Finish”.
• Open “Ganymede Discovery Site”, select “Web and Java EE Development”, and click on “Select Required”.
  
• Click on “Finish”. Like subclipse, some validation and other dialog box appear. Validate all.
• Coffee Time

Your IDE is now ready for good coding !

Maven : manager of project

Based on the concept of a project object model (POM), Maven can manage a project’s build, reporting and documentation from a central piece of information.
Maven is the perfect tool for continuous integration and version tracking of your jar, swc, war, …
For more information about Maven, visit the maven homepage.
m2Eclipse is the Maven2 plugin for Eclipse. This plug-in ads all you need to integrate Maven into your projects.

For the installation of m2Eclipse, you need to add another remote update site.

• Go to “Help > Softawre Updates > Find and install…”.
• Choose “Search for new features to Install” and click on “Finish”.
• Click on “new remote site”.
• Type “m2Eclipse” in Name input, and “http://m2eclipse.sonatype.org/update/“ in the url update address input.
  
• Click on “Ok”.
• Verify in the list of includes sites that m2eclipse is selected. Click on “Finish”.
• Now You need to select the list of Maven plug-in to install. The minimum required is to select all in the folder “Maven Integration” except POM XML Editor (for me, I have selected this feature), and POM Editor.
  
For a better integration with WTP and Subclipse, I select also the “Maven integration for WTP” (in Maven Project Configurators”) and “Maven Central repository index”, “Maven SCM handler for Subclipse” (in Maven Optional Components”).
  
• Click on “Next”.
• After passing all validations, …. Another coffee time !

Finish !

Now : restart your IDE…. And let’s gamble ! With all these coffees you can’t sleep anyway … it can be time to start your project?

Autres articles sur le même sujet

• Import de framework via SVN et le plug-in Subclipse
• Installer son environnement de développement : Tomcat – Eclipse – WTP – Flex Builder
• Maven 2 – Flex 2 – une synergie possible ?
• Flex Builder 3 et le PHP ( PDT ) : installation

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

De l’intérêt de Maven 2

Kézako

Maven 2 est un (puissant) outil open source créé pour gérer la « périphérie technique » d’un projet java : de sa description (version, dépendances) à son déploiement en passant par l’ensemble des étapes standard (compilation, tests unitaires, construction, installation, etc. …) Je ne rentrerai pas trop dans le détail, vous invitant à consulter l’article très détaillé sur maven 2 depuis le site développez.com. L’élément à bien retenir ici est le fichier de description de votre projet : le pom.xml. C’est dans ce fichier que l’ensemble des déclarations sera fait. Pour lancer maven, il vous suffit d’appeler un « but » (ou goal en anglais). Le lancer via maven consiste à dire que vous souhaitez atteindre ce but (cet objectif). Par exemple, la commande mvn compile indique que vous souhaitez compiler votre projet.

Les dépendances

L’un des éléments à retenir consiste en la gestion des dépendances d’un projet proposée avec une gestion de la résolution des dépendances induites : concrètement, il suffit d’indiquer que votre projet compte la librairie struts en version 1.3.0 dans ses dépendances, et maven ajoutera automatiquement les autres librairies nécessaires au bon fonctionnement de struts, gérant au passage tout conflit potentiel avec d’autres dépendances. Pour les Linuxiens, ce système est tout à fait similaire au fonctionnement de APT (Debian, Ubuntu) ou YUM (Red Hat, Fedora). La communauté Maven 2 maintient donc un repository public qui référence l’ensemble des librairies disponibles à l’ajout. Lors d’une compilation, l’outil rapatrie localement les JAR et les place dans un répertoire structuré de la même manière que ce repository distant, vous permettant – ce point est essentiel – d’ajouter vos propres librairies.

Les plugins

Pour rester extensible (c’est dans l’ère du temps), maven 2 gère des plugins. On compte notamment parmi eux le plugin « eclipse » générant les fichiers .classpath et .project utilisé par l’IDE au moment de la compilation. Une partie dédiée au WTP est également en place pour gérer le déploiement d’une webapp sur le serveur applicatif déclaré via ce dernier. Maven dispose d’un « repository de plugins » (URL Internet) dans lequel il va aller chercher toute déclaration de plugin faite dans votre fichier pom.xml. Par exemple, si vous déclarez l’utilisation du plugin WTP (section <build>), maven va télécharger le plugin en question et l’appliquera à votre projet.

Conclusion

A partir de ces différents constats, il devient intéressant de gérer l’ensemble du processus de déploiement d’un projet à l’aide de maven 2, pour éviter d’utiliser trop d’outils différents concernant les tâches connexes à vos développements.

Quand Flex rentre en action

Pourquoi maven 2 pour Flex ?

Maven va donc compiler la partie Java, lancer d’éventuels tests unitaires, mais dans un projet Flex, il faudra au préalable que les .as et .mxml aient été compilés et inclus dans les bons répertoires du projet. Mais qu’en est-il si l’on gère plusieurs projets et qu’ils ont en commun des libraires SWC de composants? Pas très pratique de copier les fichiers directement en tant que ressource et risquer des erreurs de copies ou de mises à niveau lors de changements de version. Heureusement, vous n’êtes pas le seul à vous être posé la question…

Le plugin Maven 2 – Flex 2

L’équipe de ServeBox propose un plugin Maven gérant la compilation et le déploiement d’applications et de librairies Flex (par le biais d’un SDK installé localement). Tous les détails sur ce plugin figurent à l’adresse suivante : Plugin Flex 2 pour maven sur ServeBox. Pour reprendre succinctement les travaux effectués à l’heure actuelle, vous devez, en plus d’installer maven 2 :

• installer les artifacts (librairies) SWC du framework Flex dans votre repository local,
• pour chaque projet :
  • déclarer le type de « packaging » de votre projet (SWF pour une application et SWC pour une librairie Flex),
  • déclarer le chemin vers le plugin de ServeBox (dans le repository de plugins) afin que le type de packaging SWF ou SWC soit reconnu, ainsi que les buts (goal) comme flex2:makeswc.

On peut donc tout à fait imaginer que vous installiez dans votre repository local des librairies comme flex-lib ou encore vos propres librairies (un framework local ou que sais-je encore), pour les utiliser comme dépendance de votre projet (au même titre qu’une dépendance Java). Un mot pose pourtant encore problème dans cette conclusion : « local ». Eh oui, vous êtes sur votre machine et ne partagez pas votre installation avec votre entourage.

Comment ajouter des librairies dans un repository partagé par un groupe de travail ?

Le problème se posait déjà dans le monde Java : il n’est pas rare qu’un projet dépende de librairies n’appartenant pas au monde libre (oracle, …) et le système (très appréciable) de gestion de dépendances de maven 2 à tendance à donner des idées pour mutualiser les développements. Une réponse existe sous le nom de Proximity. Comme vous le verrez peut-être en suivant ce lien, Proximity est un proxy pour maven. En répliquant les dépendances demandées lors d’une exécution de maven, son intérêt est multiple :

• réduire les temps de rapatriement de manière générale,
• répondre en cas d’indisponibilités ponctuelles du repository public de maven 2,
• ajouter des librairies dans des repository personnalisés fonctionnant comme le repository public de maven 2.

Selon votre organisation, vous pouvez tout à fait installer une instance de proximity pour y créer un repository personnalisé, et ainsi mutualiser vos propres librairies.

J’espère que cette approche générale sur le sujet vous donnera l’envie d’aller un peu plus loin. La prochaine fois, j’entrerai sur un cas pratique d’une application Flex développée sous eclipse WTP à l’aide de maven 2.

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

• L’erreur est humaine… debuguer un projet Flex distant via Flex Builder
• Un projet Java / Flex avec Maven 2
• FlashBuilder/Eclipse : installation guide – subclipse, PDT, WTP and Maven
• AIR 2 : appeler un JAR exécutable via un NativeProcess