On 10/20/11 11:43 AM, Guillaume Nodet wrote:
I think you first need to define your constraints and what you want to focus
on.
If you want someone to be able to write a jar to extend the api which will
work in a non osgi environment and (with minimal changes) in an osgi
environment, go for fragments.
If you want to go a cleaner osgi way, go for services, but forget about
class names in the schema directly, and you need to define two different
ways, one for osgi and one in a non osgi environment (as you won't have osgi
services at all in a flat classloader).
It's all about trade-offs.
When talking with Emmanuel this week, it seems to me that for the api,
extending the api was not a very common operation and did not really require
the osgi dynamism. Fragments are perfect for those simple use cases. But
for sure, if you ask an OSGi purist, the recommandation will be to not use
fragments.
We have two different needs :
1) provide a OSGi compliant server, including an OSGi container for
those who don't have one. That means we include Felix, and we will have
a mode that let the user set his own container, excluding Felix in this
case. We will have to provide two launchers to cover those two different
cases.
In any case, all the extension points will be plain OSGi services.
2) For the API, this is a different story, as the API will most
certainly be used outside an OSGi container, except for ADS and Studio,
which will run into Felix (ADS) and Equinox (Studio). The extension
points will be plain java classes, class-loaded using their FQCN or even
loading the bytecode stored in an entry.
This is somehow what we discussed with Guillaume yesterday, and I do
think that fragments are a good trde-off for the API.
At least, it seems to work...
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
