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 09:03:30 GMT
Sounds good to me.

Just one note, I think it should not necessarily be a sub-component of
SPI Fly. Yes, it uses that for some of its functionality, but I think
that's really an implementation detail. I think it should be a
top-level component in its own right.
Just to compare, there are other components that depend on the Aries
proxy functionality, but still they are not sub-components of



On 8 October 2012 09:47, Jeremias Maerki <> wrote:
> Hi David
> Great! I think the process should be easy:
> - We decide on a (package) name.
> - I change the package structure after that decision.
> - I'll try to come up with a POM (I'm no big Mavener)
> - I put together a submission which I'll upload to JIRA.
> - It is debatable whether I need to file a code grant but I have
> developed that all by myself and I'm an ASF member (with an ICLA on file).
> It's also not that big a contribution. So I don't think this is
> necessary.
> - The Aries committership votes on acceptance.
> So, back to naming. What shall it be?
> - org.apache.aries.spifly.consumer
> - org.apache.aries.spifly.discovery
> - org.apache.aries.discovery
> - org.apache.aries.plugin.discovery
> - org.apache.aries.spi.catch ;-)
> - other ideas?
> Cheers,
> Jeremias Maerki
> On 08.10.2012 10:02:32 David Bosschaert wrote:
>> 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,
>> David

View raw message