Pascalleclercq's Blog

13/05/2010

Customisation des plugins « Tycho »

Filed under: Eclipse RCP,Maven,OSGi,Tycho — pascalleclercq @ 9:56

Récemment Keukeul m »interrogeait sur la documentation des plugins « Tycho » (http://pascalleclercq.wordpress.com/2010/02/14/construire-ses-plugins-eclipse-rcp-avec-maven-c%e2%80%99est-plus-facile-maintenant-avec-maven-3-et-tycho/#comment-9).

Rappelons que Tycho peut être défini comme un ensemble de plugins maven destiné à la construction de livrables eclipse. La question posée par Keukeul est pour le moins légitime et pertinente !

Malheureusement, à ce jour, je ne connais pas d’article de référence concernant la configuration de ces plugins. La seule vraie solution aujourd’hui est de récupérer les exemples disponibles avec les sources de Tycho. (http://github.com/sonatype/sonatype-tycho/tree/master/tycho-its/projects/)

Je vais donc, à la demande générale exposer les différentes configuration des plugins Tycho que j’ai eu l’occasion d’utiliser en tentant d’expliquer le pourquoi.

1. tycho-maven-plugin

La présence de ce plugin est indispensable pour que maven sache interpréter les packaging Tycho (http://tycho.sonatype.org/packagingtypes.html). Un bloc de ce type est donc indispensable :

<build>
<plugin>
   <groupId>org.sonatype.tycho</groupId>
   <artifactId>tycho-maven-plugin</artifactId>
   <version>0.8.0</version>
   <extensions>true</extensions>
</plugin>
...
</build>

Je n’ai pas grand chose à dire de plus mis à part que ce bloc est indispensable pour que Tycho puisse fonctionner. Ce bloc est bien entendu à placer dans votre pom.xml « parent ».

2. maven-osgi-compiler-plugin

Ce plugin est ni plus ni moins l’équivalent du fameux « maven-compiler-plugin ». Il me sert à configurer l’équivalent du « -source » et « -target » du compilateur java.

<build>
     <plugins>
       <plugin>
         <groupId>org.sonatype.tycho</groupId>
         <artifactId>maven-osgi-compiler-plugin</artifactId>
         <version>0.8.0</version>
         <configuration>
           <source>1.6</source>
           <target>1.6</target>
         </configuration>
       
       </plugin>
     </plugins>
 </build>

Je n’ai pas testé autre chose sur ce plugin mais je pense qu’on peux raisonnablement espérer que l’essentiel voire la totalité des options du classique maven-compiler-plugin fonctionne (http://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html)

3. target-platform-configuration

A mes yeux le plugin le plus utile à connaître. En effet, tycho fonctionne par défaut avec un repository de type « file system » à plat que l’on passe en argument du build -Dtycho.targetPlatform=c:/eclipse.

Ce que l’on veut, c’est que Tycho puisse exploiter des repository à la maven voire mieux à la p2 (tant qu’à faire de l’eclipse…). Eh bien Tycho peut faire les 2 !!!!

Comment simplement en ajoutant dans votre pom.xml ce bloc :

<build>
		<plugins>
		...
			<plugin>
				<groupId>org.sonatype.tycho</groupId>
				<artifactId>target-platform-configuration</artifactId>
				<version>0.8.0</version>
				<configuration>
					<resolver>p2</resolver>
					<pomDependencies>consider</pomDependencies>
				</configuration>
			</plugin>
		</plugins>
</build>

<repositories>
		<repository>
			<id>gallileo</id>
			<layout>p2</layout>
			<url>http://download.eclipse.org/releases/galileo</url>
		</repository>

...
</repositories>

Explications :
– la balise p2 permet de dire à maven de prendre en considération lors du build les dépendances trouvées dans le dépôt p2 positionné quelques lignes plus bas sous la balise « repositories ».
– la balise consider permet d’exploiter en même temps des dépendances provenant de repository au layout maven (c’est le cas de Spring DM par exemple). Il va sans dire que ces dépendances doivent être des bundles OSGi pour être exploitables lors du build. Si vous n’avez pas besoin de dépendance provenant d’un dépôt maven cette balise ne vous sera pas utile.

4. maven-osgi-packaging-plugin

Ce packaging est utile pour la construction de « product » (= d’exécutables) eclipse. Pour rappel, pour contruire un « product » avec Tycho vous devez créer un projet séparé ne contenant u’un fichier « .product » et dont le pom.xml possède le packaging « eclipse-application ».

<plugin>
                <groupId>org.codehaus.tycho</groupId>
                <artifactId>maven-osgi-packaging-plugin</artifactId>
                <version>0.8.0</version>
                <configuration>
                <productConfigurationFile>toto.product</productConfigurationFile>
                    <environments>
                        <environment>
                            <os>linux</os>
                            <ws>gtk</ws>
                            <arch>x86</arch>
                        </environment>
                        <environment>
                            <os>win32</os>
                            <ws>win32</ws>
                            <arch>x86</arch>
                        </environment>
                        </environments>
                </configuration>
</plugin>

Remarque : Une best practice consiste à « variabiliser » le numéro de version de Tycho (0.8.0 ici) dans un propriété du pom.xml.

Un exemple de contruction d’un projet mutimodule avec tycho : http://code.google.com/p/dynaresume/source/checkout

14/02/2010

Construire ses plugins Eclipse RCP avec Maven ? C’est plus facile maintenant avec Maven 3 et Tycho !

Filed under: Eclipse RCP,Maven,OSGi — pascalleclercq @ 9:48

Il y a de cela un peu plus d’un an, lorsque je cherchais un moyen de construire un plugin Eclipse avec Maven, je tombais presque par hasard sur une réponse laconique de Jason Van Zyl (le papa de maven): « Tycho ».
Mais, me diriez-vous : On ne pouvait pas contruire de plugin Eclipse avec Maven avant ???

Eh bien, en pratique, on pouvait parvenir à compiler des sources, à générer des fichiers manifest.mf voire à construire des « product » mais à quel prix ! A titre d’illustration, je vous invite à lire l’excellent article de Cyril Lakech et vous aurez une mince idée de la sueur et des larmes qu’il fallait accepter de verser pour mettre en place Maven sur des plugins avant d’apercevoir le graal.

Une autre alternative consistait à développer et maintenir ses propres « Mojo »; Grégory Levilain a ces dernières années ainsi développé et déployé sur de nombreux projets un ensemble de plugins Maven permettant d’adopter une optique « POM-FIRST ». Cette approche laisse à Maven le soin de gérer les versions des éléments du projet (plugins, fragments, features, update-sites, products), et de leurs dépendances. Ces travaux ont été initiés en 2006 lors de la mise en open-source du projet Wazaabi.

Mais alors que fournit Tycho de si merveilleux ?

Tout d’abord, Tycho fournit un mécanisme de résolution de dépendances s’appuyant sur le fichier MANIFEST.MF du plugin. Cela présente un double intérêt :

  • Les bundles OSGi (dont les plugins Eclipse font partie) disposent d’un mécanisme de résolution de dépendances plus abouti que celui fourni par maven (dépendances non-transitives, possibilité de préserver tout ou partie des paquetages d’un bundle,…).
  • De cette façon, le développeur n’a pas à se préoccuper de l’utilisation de Maven : il peut se concentrer sur le manifest.mf comme il est censé le faire normalement dans le PDE sans se soucier du pom.xml.
  • Par ailleurs, le PDE résout les dépendances incroyablement plus rapidement que ne le feraient q4e ou m2e en s’appuyant sur les informations du pom.xml.

Au final, un pom.xml minimal permettant de construire un plugin Eclipse se réduit pratiquement toujours à :

<project>
	<modelVersion>4.0.0</modelVersion>
	<parent>
		<groupId>com.mycompany.mygroup</groupId>
		<artifactId>parent</artifactId>
		<version>0.0.1-SNAPSHOT</version>
	</parent>
	<artifactId>com.mycompany.myplugin</artifactId>
	<packaging>eclipse-plugin</packaging>
</project>

Frugal n’est ce pas ?
Bien entendu, nous allons mettre des choses un peu plus intéressantes dans le pom.xml parent.

Le PDE et la notion de target platform

Avant d’aller plus loin, il est temps à présent de fournir un petit rappel concernant la façon d’utiliser le PDE (Plugin Development Environment). Par défaut, lorsque vous développez des plugins sous Eclipse vous utilisez la « target platform » courante. C’est à dire l’ensemble des plugins qui vous ont permis de démarrer votre IDE. C’est une très bonne pratique que de définir sa propre target platform:

  • Cela permet de travailler éventuellement sur une version différente des plugins Eclipse.
  • Cela permet de travailler sur un sous-ensemble des plugins (quelques dizaines suffisent la plupart du temps).
  • Cela permet d’ajouter vos propres plugins déjà construits sans polluer votre IDE.

Vous trouverez l’ensemble des target platform sous Eclipse dans « Windows–> preferences ->Plug-in Development -> Target Platform »

En somme, la target platform fournit les mêmes fonctionnalités qu’un repository Maven.

Il est donc tout à fait naturel de retrouver cette notion dans la résolution de dépendances de builds Tycho. Tycho propose actuellement 2 façons de résoudre la target platform utilisée pour ses builds.

  1. Par le biais du filesystem
  2. mvn  clean install -Dtycho.targetPlatform=c:/eclipse3.5
  3. De façon beaucoup plus élégante, par le biais de repository P2 et maven combiné
  4. <project>
      <modelVersion>4.0.0</modelVersion>
      <groupId>org.dynaresume</groupId>
      <artifactId>parent</artifactId>
      <version>0.0.1-SNAPSHOT</version>
      <packaging>pom</packaging>
      <modules>
        <module>infrastructure</module>
        <module>bundles-api</module>
        <module>bundles-impl</module>
        <module>bundles-ui</module>
      </modules>
      <build>
      <plugins>
            <plugin>
            <groupId>org.sonatype.tycho</groupId>
            <artifactId>tycho-maven-plugin</artifactId>
            <version>0.6.0</version>
            <extensions>true</extensions>
            </plugin>
            <plugin>
            <groupId>org.sonatype.tycho</groupId>
            <artifactId>target-platform-configuration</artifactId>
            <version>0.6.0</version>
            <configuration>
                <resolver>p2</resolver>
                <pomDependencies>consider</pomDependencies>
            </configuration>
            </plugin>
        </plugins>
       </build>
    
     <repositories>
           <repository>
            <id>gallileo</id>
            <layout>p2</layout>
     <url>http://download.eclipse.org/releases/galileo</url>
            </repository>
    
            <repository>
             <id>com.springsource.bundles.release</id>
             <name>SpringSource Bundle Releases</name>
             <url>http://repo.spring.com/release</url>
            </repository>
    
            <repository>
               <id>com.springsource.bundles.external</id>
               <name>External Bundle	Releases</name>
               <url>http://repo.spring.com/external</url>
            </repository>
    
        </repositories>
    </project>
    

Conclusion

Cela laisse présager des jours heureux pour tous les développeurs RCP. A titre individuel, je commence fortement à songer à l’utilisation de Tycho pour construire et assembler en headless non seulement des plugins RCP mais aussi tous les bundles OSGi qui se présentent.

Mais alors, vous allez me dire pourquoi n’ai je pas utilisé Tycho plus tôt ?

Principalement parce que Tycho ne fonctionne qu’avec Maven 3 dont les pseudo release alpha-x sont à peine sorties. Toutefois, rassurez vous, vos pom.xml actuels sont censés être parfaitement portables vers Maven 3. Des centaines de tests unitaires sont utilisés pour vérifier cela et actuellement il ne semble pas y avoir de défection.

Il subsiste un point sur lequel Tycho n’apporte pas à ce jour de réponse satisfaisante à ceux qui sont habitués aux cycles de développements fournis par Maven : la synchronisation pom.xml/manifest.mf lors de la phase de release. Ceci est en passe d’être corrigé dans la version 0.7.0.

Pour aller plus loin :

Thème Rubric. Propulsé par WordPress.com.

Suivre

Recevez les nouvelles publications par mail.