• 'Building with Tycho - part 1, OSGi bundles'
• 'Building with Tycho - part 2, RCP Applications'
• 'Building with Tycho - part 3, Testing, Code coverage and easier development using Target Definitions'

IBM propose une preview (version 0.5) de son futur outillage dédié au devéloppement d'applications OSGi.

Dans l'interview 'Apache Aries: Marrying OSGi with Java EE', l'un des contributeurs du projet Apache Aries fait le point sur l'avancement de ce projet qui a pour but de fournir une plate-forme basée sur la spécification OSGi Enterprise.

Angelo Zerr vient de publier la 19ème et dernière partie de son tutorial 'Conception d'un client Eclipse RCP et serveur OSGi avec Spring DM'. Le niveau de détail est impressionnant et l'approche progressive devrait répondre à de nombreuses questions. Le plan complet du tutorial est consultable sur cette page.

Sonatype, la société derrière Maven, propose que Tycho devienne un projet officiel de la fondation Eclipse. Tycho rend l'utilisation de Maven de façon quasi-transparente pour la construction des applications OSGi (et donc Eclipse RCP).

Le support de la présentation 'OSGi & Java EE in GlassFish' est disponible . Il donne un bon aperçu de la façon dont Glassfish permet aux développeurs d'exploiter le meilleur des deux mondes (JavaEE et OSGi).

Non, je n'ai pas fait une erreur de frappe en tapant le titre de cette news. Qwylt est un projet, plus ou moins interne, lancé par Oracle début 2009. Ce projet correspond à ce qui a été évoqué lors d'une présentation animée par deux responsables importants d'Oracle (notamment le responsable de la stratégie Java).

Le but de Qwylt est de proposer une API permettant d'interargir avec des systèmes de gestion de modules. Le peu d'informations données actuellement laissent supposer que Qwylt pourrait être intégré au JDK 7. Qwylt ne remplace pas OSGi ou tout autre système de module, son but est de créer un niveau d'abstraction masquant le système de gestion de modules utilisé. La première justification à cette approche est de trouver un moyen permettant d'utiliser à la fois OSGi et Jigsaw (le système de modules interne au JDK 7). Espérons qu'Oracle donnera plus d'informations prochainement.

La spécification OSGi Enterprise vient d'être publiée en version finale. Cette spécification marque une étape importante pour OSGi. Elle décrit notamment comment OSGi peut s'intégrer dans un contexte JavaEE. Jusqu'à maintenant, OSGi s'est développée en parallèle du monde JavaEE, d'où certaines difficultés pour faire cohabiter les deux mondes. Avec les projets Eclipse Virgo, Eclipse Gemini et Apache Aries, des implémentations d'une bonne partie de cette spécification sont dès aujourd'hui disponibles. Parions qu'avec cette spécification, OSGi va prendre une nouvelle dimension.

Cette page donne un premier aperçu synthétique du contenu de la spécification,

Dans l'article 'OSGi, and How It Got That Way', Neil Bartlett choisit d'expliquer les concepts d'OSGi d'une façon originale et intéressante. Il se replace dans un contexte où OSGi n'existerait et il déroule un à un les besoins d'un système modulaire en Java et les solutions qui lui semblent les plus logiques. Bien évidemment, il arrive à la fin à la recréation d'OSGi.
Sur le fond il y a plusieurs remarques intéressantes, notamment le fait de bien préciser que l'aspect dynamique d'OSGi n'est pas un point principal mais une conséquence offerte pas des choix vraiment fondamentaux (un classloader par module et un conteneur donnant une existence aux modules lors de l'exécution).

Un article en français sur les choix possibles pour réduire les dépendances cycliques entre modules OSGi.

Dans l'interview 'Using OSGi and Equinox effectively', l'auteur du livre 'OSGi and Equinox' répond à plusieurs questions intéressantes. Parmi ses conseils sur l'utilisation d'OSGi, il y en a deux qui ne sont pas assez souvent exposés :

• limiter au maximum les appels aux API propres à OSGi (en privilégiant une approche déclarative).
• éviter d'utiliser les BundleActivator. Leur utilisation doit être exceptionnelle. Effectuer systématiquement des tâches d'initialisation dans les BundleActivator peut avoir un impact fort sur les temps de démarrage.

Fin février s'est tenue la session londonienne de la conférence OSGi DevCon. Le support de la session d'ouverture est consultable sur le site de son auteur. Cette présentation est intéressante car elle est se concentre exclusivement sur le problème de la complexité des logiciels pour démontrer l'importance de la notion de modularité.

Le premier slide attaque fort avec cette phrase: "OSGi is a disruptive technology that will transform how enterprise Java applications are designed, developed and managed !".

La littérature consacrée à OSGi s'étoffe progressivement avec la sortie notable du livre 'OSGi and Equinox'. Deux chapitres sont librement consultables.

Pascal Leclerq nous propose un retour sur ses tests prometteurs de Tycho (outillage facilitant l'utilisation de Maven dans un contexte OSGi ou Eclipse RCP).

Un article qui résume les outils disponibles pour utiliser sur un même projet OSGi et Maven.

'OSGi Declaratives Services' est une solution pour décrire les relations entre les composants d'une application OSGi. Les articles 'Declarative Services: Delayed Components' et 'Declarative Services: Configuration' abordent deux aspects de la spécification 1.1 de ce service.

SpringSource annonce avoir déposé une proposition pour la création du sous-projet Virgo. Ce projet sera créé à partir du code de la version 2.0 de Spring dm (Spring dynamic modules est un serveur d'applications Java basé sur OSGi).

L'actualité d'OSGi en entreprise est dense en cette fin d'année : après l'annonce de la création du projet Gemini par Oracle et Spring Source, c'est IBM qui propose son implémentation de la spécification 'OSGi Entreprise'.
Cette implémentation, nommée 'OSGi Applications Open Alpha', permet d'ajouter à un serveur WebSphere 7 les fonctionnalités de déploiement et d'exécution de modules OSGi.

Avec le soutien d'Oracle, d'IBM, des communautés Spring, Glassfish et JOnAS, il ne fait maintenant plus de doute que l'utilisation d'OSGi côté serveur va se généraliser.

En attendant la version finale pour début 2010, l'early draft 4 de la spécification 'OSGi Enterprise' est disponible. Cette spécification est celle sur laquelle s'appuiera le projet Gemini de la fondation Eclipse.

SpringSource et Oracle ont publié la proposition de création du projet 'Enterprise Modules Project', nom de code 'Gemini'. Ce projet a pour but de faire le lien entre OSGi et les technologies Java serveur. Des sous-projets seront créés pour implémenter les spécifications publiées par 'l'OSGi Enterprise Expert Group'.