Eclipse : déployer un produit headless

Une étape importante du développement d'une application basée sur Eclipse RCP est l'automatisation du déploiement du produit. Pour ce faire, l'IDE met à disposition une série de tâches ANT permettant d'externaliser cette tâche.

Il existe cependant différents "niveaux d'automatisation" :

• Ecriture d'un script ANT utilisable seulement depuis l'IDE
• Utilisation d'un batch s'appuyant sur le moteur de l'IDE (Equinox)
• Insertion dans un cycle d'intégration continue

Je vais donc ici essayer de présenter les différentes ressources pour mettre en place chacune de ces méthodes.

Ecriture d'un script ANT utilisable seulement depuis l'IDE

Pour démarrer l'élaboration du script ANT principal, la meilleure source est cet article de Lars Vogel. Il contient les premiers éléments indispensables. Contenu du script :

<project default="main">
 <property file="build.properties"/>
 <target name="main">
  <property name="baseLocation" value="${eclipse.home}"/>
  <!-- by default, check for deltapack co-located with eclipse -->
  <property name="deltapack" value="${eclipse.home}/deltapack/eclipse"/>

  <!-- Check that we have a deltapack -->
  <available property="haveDeltaPack" file="${deltapack}"/>
  <fail unless="haveDeltaPack" message="The deltapack is required to build this product.  Please edit buildProduct.xml or set the &quot;deltapack&quot; property." />
   
  <property name="builder" value="${basedir}" />
  <property name="buildDirectory" value="${basedir}/buildDirectory"/>
  <property name="pluginPath" value="${basedir}/..${path.separator}${deltapack}" />
  <property name="buildTempFolder" value="${buildDirectory}" />
   
  <ant antfile="${eclipse.pdebuild.scripts}/productBuild/productBuild.xml" />

  <move todir="${basedir}">
   <fileset dir="${buildDirectory}/${buildLabel}" includes="*.zip"/>
  </move>

  <!-- refresh the workspace -->
  <eclipse.convertPath fileSystemPath="${basedir}" property="resourcePath"/>
  <eclipse.refreshLocal resource="${resourcePath}" depth="infinite"/>
 </target>
</project>

Comme on le voit, ce script utilise principalement certaines tâches internes d'Eclipse (eclipse.convertPath...) ainsi qu'un autre script faisant l'essentiel du travail : ${eclipse.pdebuild.scripts}/productBuild/productBuild.xml. Situé dans le plugin plugins\org.eclipse.pde.build_[version] il défini notamment la tâche eclipse.generateFeature, point de départ du déploiement. Le fichier de propriétés quant à lui contient essentiellement la configuration habituellement valorisée par l'IDE lors de l'utilisation de la fonctionnalité d'export de produit classique.

Il peut être nécessaire lors d'une livraison d'ajouter certains répertoires à la racine de l'archive créée, pour des besoins métier, par exemple le JRE. Pour ce faire, il faut définir, dans les features, les ressources "root". Par exemple, dans le fichier build.properties d'une feature, ajouter la ligne :

root.folder.jre = absolute:${eclipse.home}/jre

Ainsi sera créé un répertoire nommé "jre" contenant la version du JRE présente à l'emplacement spécifié.

Utilisation d'un batch s'appuyant sur le moteur de l'IDE (Equinox)

Le script ANT tel que décrit ci-dessus nécessite l'ouverture d'Eclipse pour s'exécuter dans la même JRE. Il est cependant possible de simuler la présence de l'IDE sans pour autant lancer l'IHM grâce à l'exécution directe de son moteur : Equinox. Voici un exemple de batch :

java -jar ../../plugins/org.eclipse.equinox.launcher_1.2.0.v20110502.jar -application org.eclipse.ant.core.antRunner -buildfile buildProduct.xml -Dfile.encoding=UTF-8

Le lanceur Equinox est alors utilisé pour démarrer le plugin de lancement de script ANT. Le déploiement devient donc totalement indépendant de l'IDE (ou du moins de sa partie graphique!).

Il existe tout de même un bémol avec cette méthode : puisque le batch ne fait appel qu'au plugin ANT, toute configuration apportée par le workspace est perdue, principalement la gestion des encodages de fichiers. Il est certes possible de définir la propriété -Dfile.encoding mais qui devient alors unique pour toute la phase de déploiement... Si certains fichiers nécessitent une compilation (ou une simple sauvegarde) dans un autre encodage, il sera corrompu. Si je me trompe, je suis preneur de toute solution sur ce point! :-)

Insertion dans un cycle d'intégration continue

Je n'ai personnellement pas testé ce système mais Ralf Ebert a écrit un tutoriel très complet sur la mise en place de Buckminster et Hudson.

Bon courage!

Sources :

• http://help.eclipse.org/galileo/index.jsp?topic=/org.eclipse.pde.doc.user/tasks/pde_rootfiles.htm
• http://blog.ankursharma.org/2010/06/headless-build-for-beginners-part-i.html
• http://www.lorenzobettini.it/2012/11/building-xtext-projects-with-buckminster/

Fichier(s) joint(s) :