aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Bosschaert <david.bosscha...@gmail.com>
Subject Re: [SPI Fly] Interest for a more dynamic plug-in/service discovery API?
Date Thu, 01 Nov 2012 10:49:53 GMT
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 <dev@jeremias-maerki.ch> 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 <david.bosschaert@gmail.com> 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 <dev@jeremias-maerki.ch> 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 <dev@jeremias-maerki.ch>
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 <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