aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Bosschaert <>
Subject Re: [SPI Fly] Interest for a more dynamic plug-in/service discovery API?
Date Mon, 08 Oct 2012 08:02:32 GMT
Hi Jeremias,

On 5 October 2012 14:58, Jeremias Maerki <> wrote:
>> Next question is would it make sense to add this functionality to Aries?
>> I think it does. To me many of the ideas in here match with the OSGi
>> Connect RFP 145 ( and
>> I think that, besides its practical use today, this code could be a
>> valuable input to the standardization process of OSGi Connect. Overall
>> the charter of OSGi Connect is to create a dynamic services
>> environment that works both inside OSGi and out. To me the overall
>> goal of your code seems similar.
>> If we all agree that it would be suitable for this component to reside
>> in Aries, I think we should strive to make it ultimately compliant
>> with the OSGi Connect spec, when that's available.
>> Does this make sense to you?
> As I understand it OSGi Connect's goal is to use a subset of the OSGi
> framework (most importantly the service layer but not the module layer).
> So you can use the OSGi ServiceTracker to lookup services. In that case,
> my library isn't needed and probably not very useful, since it actually
> strives not to use OSGi APIs at all. So, I'm not quite getting your
> point here. I got about one too many hints that some people may have
> reservations when introducing OSGi to a plain Java project ("Do we all
> have to learn OSGi? Can I still use X in plain Java? etc."). OSGi,
> unfortunately, is still not as widely adopted as I would like. I've
> noticed how a low-level ServiceTracker can provoke reactions like: "Does
> it have to be that complicated?" At least, until they get the power of
> it. So, my main goal was to really just shield everyone from OSGi as
> much as possible. Basically, I just wanted to provide an easy migration
> path without the requirement to learn about OSGi beyond including
> manifest metadata. If my thingy helps OSGi Connect, that's great but I
> frankly don't see how. I'm probably still missing something.

I get your point. From a very high level both OSGi Connect and your
project aim at getting to use OSGi easier, however OSGi Connect
strives to do this by introducing the OSGi APIs early (before the
modularity layer) whereas your approach strives to do this by
introducing the OSGi APIs late (or not at all, even).

Personally I think choice is good and it's up to the users to really
decide what technology they want to use. I think your technology would
be at the right place in Apache Aries, so if you're happy to donate it
I would be happy to support that and I can find out the process by
which this should be done.

All the best,


View raw message