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 <[email protected]> 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 <[email protected]> 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 > >
