Maybe I misread Jeremias' email. When he said: "I'd argue that IP clearance is absolutely necessary in this case"
I thought he was saying he was going to do the s/w grant form. Now I've reread his email, it does seem a bit mixed up. Patch to JIRA, with code acceptance vote fine with me. Cheers, Jeremy On 1 November 2012 10:49, David Bosschaert <[email protected]> wrote: > Just wondering what the status is with this contribution... Since > Jemerias doesn't think IP clearance is necessary, will we simply go > ahead with an acceptance vote, which Jemerias can kick off himself, > IIUC? > > Cheers, > > David > > On 23 October 2012 07:25, Jeremias Maerki <[email protected]> wrote: >> Thanks for your feedback, Jeremy! I'd argue that IP clearance is >> absolutely necessary in this case since it's a clean-room development >> entirely by me, it's a relatively small codebase and I'm an Apache >> member with an ICLA on file. But I have no problem going through with it >> if this is preferred. After all, I've guided a larger contribution >> through back in 2006 already. >> >> >> Jeremias Maerki >> >> >> On 22.10.2012 17:26:12 Jeremy Hughes wrote: >>> On 22 October 2012 11:01, David Bosschaert <[email protected]> >>> wrote: >>> > 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? >>> >>> Sure. The voting process dictates whose votes are binding and I would >>> expect one of those people to commit the code if the vote is >>> successful. >>> >>> Jeremias, I support you bringing this to Aries. Thank you (in fact I >>> already mentioned it our last board report that you had contributed >>> it :-) Since you developed your code outside the ASF you should look >>> at: http://incubator.apache.org/ip-clearance/index.html >>> >>> Thanks you! >>> >>> > >>> > 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 >>> >>> > >> > >>> >>> > > >>> >> >>
