« Pour revenir à la RFC 124, auriez-vous des informations sur les débats internes de l’Enterprise Expert Group qui ont mené à une RFC dans laquelle on ne retrouve pas d’inspiration de Declarative Service ou de Felix iPOJO ? »

La RFC est directement tiré de Spring-DM et comme vous l’avez remarquer ne s’inspire pas vraiment des autres modèles à composants sur OSGi( Service Binder, SCR, Dependency Manager, iPOJO et bien d’autres). Cette RFC est plutot destiné au développeurs utilisant « Spring » (c’est à dire un développement type JEE). Cependant, cette RFC ne garde pas vraiment la philosophie d’OSGi (small, ‘simple’, dynamic).

C’est là, la plus grosse différence, iPOJO a été bati pour OSGi sur OSGi. Spring-DM est une migration de Spring sur OSGi. D’ailleurs, Spring-DM profite de touts les services techniques de Spring. Ceux-ci sont très utiles mais gardent une connotation JEE. Cependant, faire tourner une application Spring-DM sur J2ME me semble complexe, alors qu’il existe des applications iPOJO tournant sur Android, NSLU (JamVM), voir des périphériques encore plus petits (JVM Mika) …

Concernant les discussions de l’EEG, Richard Hall (Apache Felix leader et l’un des ‘défendeurs » d’iPOJO) fait parti de l’EEG et discute régulièrement avec les autres participants (dont Hal Hildebrand et Adrian Coyler).

PS pour Etienne: l’équipe d’iPOJO va bientôt fournir un tutorial complet concernant les annotations.

Clement

Je pense qu’iPojo et Spring DM sont très différents. Avec les deux on peut utiliser des descripteurs XML. Sur ce point ils sont « comparable ».
Mais iPojo peut aussi fonctionner à l’aide d’annotation (http://felix.apache.org/site/how-to-use-ipojo-annotations.html). Cette fonctionnalité est très pratique et correspond bien à la tendance actuelle. C’est ce mode que j’utilise.
En fait le fonctionnement d’iPojo par annotation n’est pas très facile à appréhender car il n’est pas mis en avant sur le site d’iPojo. Il est regrettable qu’il n’y ait pas de tutorial sur l’utilisation d’iPojo avec les annotations. Quand on utilise les annotations, le descripteur XML reste utile uniquement pour déclarer les instances qu’iPojo doit fabriquer.

Etienne

Si nous ne nous sommes pas attardés sur Apache Felix iPOJO, nous n’avons en aucun cas voulu donner l’impression que ce projet était « mort ».

Nous avions initialement prévu de placer iPOJO aux côtés de Spring DM comme successeur potentiel du très récent Declarative Service (2005) qui lui même devait proposer un modèle de programmation plus simple que le couple ServiceTracker/BundleActivator.

Cependant, nous avons eu l’impression que le modèle de Spring DM faisait l’unanimité au sein de l’OSGi Alliance avec notamment l’éloge qu’en a fait Peter Krien, Director of technology de l’OSGi Alliance, dans Spring and OSGi: Jumping Beans (01/2007) puis l’annonce d’Eric Newcomer, co-chair de l’OSGi Enterprise Expert Group, dans Early Draft OSGi V4.2 Docs Available : la V4.2 introduirait avec la RFC 124 un nouveau modèle de composants inspiré par Spring DM [1].

La culture de débats ouverts du Java Community Process ne nous avait pas habitué à ce qu’une spécification semble exclusivement inspirée par un produit déjà sur étagère sans que les autres acteurs de l’expert group apportent leur contribution mais c’est bien la tournure que semble prendre « RFC 124 – A Component Model for OSGi ».

La seule tentative de débat public que nous ayons trouvée sur ce point, Gunnar Wagenknecht’s weblog – OSGi RFC 124, a malheureusement tourné court avec la réponse cinglante d’un membre de l’OSGi Enterprise Expert Group, Hal Hildebrand – Oracle, qui a avancé des arguments aussi constructifs que « Dude, since I haven’t seen you operating in the EEG committee » … quand on se souvient que l’OSGi Alliance demande 20 000 $ pour participer à ces comités, on regrette le JCP qui lui accueille gratuitement les membres individuels et a des débats de plus en plus souvent publics.

Pour revenir à la RFC 124, auriez-vous des informations sur les débats internes de l’Enterprise Expert Group qui ont mené à une RFC dans laquelle on ne retrouve pas d’inspiration de Declarative Service ou de Felix iPOJO ?

Cyrille (Xebia)

[1] « The big new areas of course are the distributed OSGi and the « Spring-inspired » component model ». Plus de détails dans OSGi 4.2 Early Draft / RFC 124 – A Component Model for OSGi

Interessante cette présentation. Cependant, la description d’Apache Felix iPOJO aurait été également utile (http://ipojo.org). Ca aurait d’ailleurs répondu à une question : qu’utilise le serveur JEE Jonas pour gérer la complexité d’OSGi…

De plus, ce projet est loin d’être « mort » vu qu’il rassemble de plus en plus d’utilisateurs et que la pérénité du support et du développement est aujourd’hui assuré.

Clement