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 Mon, 22 Oct 2012 10:01:08 GMT
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 <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