aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Hughes <hugh...@apache.org>
Subject Re: [SPI Fly] Interest for a more dynamic plug-in/service discovery API?
Date Thu, 08 Nov 2012 10:16:19 GMT
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 <david.bosschaert@gmail.com> 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 <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