aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremias Maerki <...@jeremias-maerki.ch>
Subject Re: [SPI Fly] Interest for a more dynamic plug-in/service discovery API?
Date Mon, 08 Oct 2012 09:34:53 GMT
Agreed. So, let's narrow down the name suggestions to two:

- org.apache.aries.discovery
- org.apache.aries.spicatch (SPI Catch, i.e. the opposite of SPI Fly)

I prefer the latter since it has a cheeky touch and still retains the
relationship with SPI Fly.

WDYT? Better ideas?

Cheers,
Jeremias Maerki


On 08.10.2012 11:03:30 David Bosschaert wrote:
> 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
> aries-proxy.
> 
> Cheers,
> 
> David
> 
> On 8 October 2012 09:47, Jeremias Maerki <dev@jeremias-maerki.ch> 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 <dev@jeremias-maerki.ch> 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 (http://www.osgi.org/bugzilla/show_bug.cgi?id=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
> >


Mime
View raw message