aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremias Maerki <...@jeremias-maerki.ch>
Subject Re: [SPI Fly] Interest for a more dynamic plug-in/service discovery API?
Date Mon, 22 Oct 2012 07:04:59 GMT
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