Bundelisation d'un jar existant

Last Updated on Mardi, 17 février 2009 06:25 Written by Henri Gomez Mardi, 17 février 2009 06:25

Je cherchais depuis quelques temps une méthode simple pour bundleiser certains de nos artifact maven en bundle osgi.

Le problème ne se pose pas pour les projets sur lesquels nous avons les sources en insérant le plugin dans le cycle existant via :

<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">

<plugin>
<artifactId>maven-jar-plugin</artifactId>
<configuration>
<archive>
<manifestFile>${project.build.outputDirectory}/META-INF/MANIFEST.MF</manifestFile>
</archive>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<executions>
<execution>
<id>bundle-manifest</id>
<phase>process-classes</phase>
<goals>
<goal>manifest</goal>
</goals>
</execution>
</executions>
</plugin>

Cependant dès qu’on utilise des artifacts externes et sans sources, comme les jars jt400 ou mqseries, on a plusieurs possibilités

Inserer le MANIFEST dans un jar existant, délicat opération manuelle.
Utiliser eclipse pour refaire un plugin depuis un jar existant. Simple mais ne peut être industrialisé.
Utiliser le plugin maven-bundle-plugin.

C’est cette troisième voie que j’ai utilisé et de manière très simple :

- on définit un projet bundle
- on ajoute la dépendance à l’artifact que l’on souhaite bundliser
- on utilise maven-bundle-plugin avec Embed-Dependency en précisant inline=true

<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.mycorp</groupId>
<artifactId>net.sf.jt400</artifactId>
<packaging>bundle</packaging>
<name>net.sf.jt400</name>
<version>6.4.0</version>
<description>Bundle OSGI de JT400</description>
<build>
<plugins>
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<extensions>true</extensions>
<configuration>
<instructions>
<export-Package>com.ibm.as400.*</export-Package>
<embed-Dependency>com.ibm.as400.*;scope=compile;inline=true</embed-Dependency>
</instructions>
</configuration>
</plugin>
</plugins>
</build>
<dependencies>
<dependency>
<groupId>net.sf.jt400</groupId>
<artifactId>jt400-full</artifactId>
<version>6.4</version>
<scope>compile</scope>
</dependency>
</dependencies>
</project>

Jetty chez Eclipse, quid de Tomcat ?

Last Updated on Jeudi, 18 décembre 2008 04:58 Written by Henri Gomez Jeudi, 18 décembre 2008 04:58

Bien que j’adore Tomcat et que je l’utilise depuis des années, je dois dire que j’ai des doutes sur son futur.

Peut être est-ce le fait d’être la référence d’implémentation qui le rend quelque part si immuable.

Il utilise toujours Ant alors que plus d’une fois a été proposée l’utilisation Maven.

Ceci aurait permis d’avoir un processus de construction plus ouvert et en phase avec la plupart des projets de l’ASF. De même les artifacts des composants Tomcat auraient pu être repensés dans ce mode.

Quand on pense modularisation du projet et artifact, on est quelque part pas très loin de se dire qu’il pourrait donc devenir OSGIfiable.

La aussi, il y a eu des propositions d’OSGIfier Tomcat, mais les développeurs n’ont pas été très chaud et l’idée est retombée.

Pendant ce temps, le ‘petit’ projet Jetty, peut être plus réactif et ouvert, n’a pas hésité à retenir Maven et surtout OSGI. D’ailleurs Jetty est le containeur préféré des plugins war maven car il est aussi très léger.

La consécration de Jetty arrive, d’abord il a été retenu par Google pour GWT 1.6, ensuite son support OSGI lui ouvre les portes d’Eclipse. Et au final, c’est son core développeur qui s’interroge sur le passage du projet sous l’ombrelle Eclipse.

On savait depuis longtemps que le containeur de servlet n’était plus la partie maitresse d’une infrastructure applicative Web, et qu’il devenait donc un composant à part entière.

C’est ce qu’on voit avec l’embarquement d’un Tomcat modifié dans JBOSS AS ou d’un Grizzly dans Glashfish.

Certains développeurs Tomcat, comme Costin, défendent depuis longtemps, l’idée d’un Tomcat léger (tomcat-lite) avec des modules plugables. Cela vous rappelle surement quelque chose non ? Effectivement, c’est ce qui a fait le succès du serveur Apache HTTPd, un core HTTP et de multiples modules, développé par l’ASF ou à l’extérieur.

J’espère sincèrement que cette approche sera retenue rapidement, surtout en cette période de réflexion sur l’après Tomcat 6, et ce que j’aimerais voir :

• un micro noyau
• l’utilisation d’autre composants de l’ASF (je pense notamment à MINA)
• une véritable approche vers des modules (à la façon d’Apache HTTPd)
• l’utilisation d’OSGI, pas parce que c’est la mode, mais parce qu’un composant doit pouvoir être changé à chaud.

En tout cas, chapeau à l’équipe de Jetty, qui loin des contraintes d’être une référence d’implémentation, a su rester à l’écoute des utilisateurs (et pas seulement des SPECS) et évoluer dans le bon sens. Si l’intégration à Eclipse se fait, ce sera quelque part une énorme reconnaissance de leur savoir faire.

OSGI dans Java 7 ?

Last Updated on Lundi, 15 décembre 2008 04:22 Written by Henri Gomez Lundi, 15 décembre 2008 04:22

Aura t’on droit à un support OSGI dans Java 7 ?

Rien n’est moins sur mais 2 articles, celui présent sur le blog OSGI et le post sur le blog de Mark Reinhold semble indiquer un changement d’attitude coté Sun.

La JSR 277 ayant fait long feu, il semblerait que l’on se pose de bonnes questions sur OSGI qui buzz ou pas, n’en reste pas moins une implémentation qui fonctionne.