I'm not sure what the rules are here but if you can't propose it as a non-committer I would be happy to propose it for you.
Anyone else any thoughts? Cheers, David On 22 October 2012 08:04, Jeremias Maerki <[email protected]> wrote: > Dear gods of war, ;-) > > would it be ill taken if I started an acceptance vote on this as a > non-committer? I'd like to get a decision since I need to know soon if > this will live on under org.apache package names or not. It doesn't > really matter to me which way in the end. > > Thanks! > Jeremias Maerki > > > On 09.10.2012 17:00:21 Jeremias Maerki wrote: >> Thanks for the additional proposal! Spire is quite nice, but in the end >> I went with SPI Catch for now as it emphasizes the relationship with SPI >> Fly. I have no problem renaming it, though. >> >> I've opened https://issues.apache.org/jira/browse/ARIES-938 and attached >> the initial submission. >> >> You're absolutely right about the possible confusion with distributed >> discovery. I have a little such component of my own that has "discovery" >> in its name. Sticking with a reference to "SPI" is certainly a good >> thing. >> >> There is a little snag that currently, the OSGI-side integration test >> doesn't work for some reason when running from within the Maven build. >> It works for me inside Eclipse. I've spent more than half my day >> tracking this down but so far to no avail (suggestions welcome). But I >> don't think this should block an acceptance vote. >> >> So, any questions, objections or other comments on this proposal? >> >> If not I'd be grateful if the Aries committership would vote on the >> acceptance of the new component. Please note that this is not intended >> as a code drop. I plan to make further live tests and to publish the >> necessary changes to Apache FOP and Batik to apply SPI Catch and make >> those projects first-class OSGi citizens. The bundles are going into a >> a test environment of an application that is planned to go live in >> January 2013. However, I don't expect SPI Catch to gain considerably >> more functionality in the future since its scope is rather narrowly >> defined. But I'm dedicated to hanging around here to help anyone who >> finds this useful. If it can help flesh out OSGi Connect, all the better. >> I'll also try to help out with SPI Fly and other topics. >> >> Thanks, >> Jeremias Maerki >> >> >> On 08.10.2012 11:44:00 David Bosschaert wrote: >> > Hi Jeremias, >> > >> > I wouldn't take the discovery one as discovery in the OSGi context is >> > often associated with distributed discovery in the context of the >> > Remote Services and Remote Service Admin specs. >> > >> > I just came up with one other name suggestion: Spire (where SPI stands >> > for SPI and 'RE' stands for reuse both inside and outside of OSGi >> > contexts :-) >> > >> > In any case the name is probably not super important right now. Just >> > pick one that you like for the submission proposal. Refactoring tools >> > in IDEs like Eclipse should make it easy enough to rename later if >> > someone comes up with a better name. >> > >> > Cheers, >> > >> > David >> > >> > On 8 October 2012 10:34, Jeremias Maerki <[email protected]> wrote: >> > > 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 >> > >> > >> > > >
