incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <>
Subject Re: [PROPOSAL] Apache Aries incubator for Enterprise OSGi
Date Fri, 04 Sep 2009 19:49:42 GMT
On 9/4/09 9:05, Daniel Kulp wrote:
> As a point of note, not all OSGi spec implementations live in Felix even at
> Apache today.   The Remote Services/Distributed OSGi reference implementation
> is a sub project of CXF.     I think Tuscany has an implementation as well.
> So far, there hasn't been any discussion about moving those into Felix.  Your
> argument below makes it sound like they should be.

Actually, I had conversations with the CXF/DOSGi team at IONA during its 
development. We discussed the technological approach as well as the 
potential home. My position was/is:

   1. If it is tied to CXF and it not generally useful without it, then
      it is reasonable for it to be hosted at CXF.
   2. If it is completely general and of interest to a general user, not
      just a CXF user, then it is reasonable for it to be hosted at Felix.

Since they felt it was fairly specific to CXF, that's where it ended up.

So, no, I am not saying "everything should", but in general, it would be 
nice if the spec impls started there since we have a community of OSGi 
users and OSGi experts who are very active and receptive, many of whom 
also work in the EE space.

In short, it makes sense for spec impls tied to the Aries component 
model (for example), to be hosted there, but there is little need to 
create another project to incubate generic OSGi spec impls, since the 
Felix community was set up for that. The reality is, most OSGi specs are 
not huge projects so we likely wouldn't want TLPs for all of them, but 
nothing stops a subproject started at Felix from going TLP if it takes 
on a life of its own.

-> richard

> Dan
> On Thu September 3 2009 1:33:04 pm Richard S. Hall wrote:
>> There was no attempt to contact the Felix PMC in general that I am aware
>> and I certainly didn't know about it in advance.
>> And there seems to be a continued attempt to construe my original
>> criticisms as "all of Aries should go into Felix".
>> I, personally, do not believe that all of Aries should go into Felix, I
>> too think it should have its own identity. I was always only ever
>> referring to the independent OSGi spec implementations. I was arguing
>> that Felix is a good place to work on them, since it is part of what it
>> is trying to achieve.
>> Further, I don't really understand the implication that somehow the
>> burden is now on the Felix community to go and contribute to Aries on
>> OSGi spec implementations just because of this proposal, when there was
>> no attempt to work with the Felix community on creating OSGi spec
>> implementations in the first.
>> The only conclusions I see being drawn by people who have invested very
>> little in Felix is that we should dismantle the Felix charter so that we
>> can accommodate the fact that some people don't want to play with us.
>> At that rate, I stand by my previous "vote" and otherwise people can do
>> whatever they want in Aries.
>> ->  richard
>> On 9/3/09 13:23, Niclas Hedhman wrote:
>>> Kevan,
>>> Was a contact with Felix made prior to dropping the proposal here? I got
>>> the impression that wasn't the case, which I find surprising... If I am
>>> wrong, what was the meat of such?
>>> I'm also less happy with the rhetoric here repeated over and over,
>>> seemingly uninterested in discussion of reaching a solution everyone can
>>> accept. (From both camps, btw)
>>> -- Niclas
>>> On Sep 4, 2009 12:53 AM, "Kevan Miller"<>   wrote:
>>> On Sep 3, 2009, at 12:53 AM, Niclas Hedhman wrote:>   On Thu, Sep 3, 2009
>>> at 3:19 AM, William A. Ro...
>>> Totally agree. Had certainly hoped that Felix committers would be
>>> interested in joining...
>>> --kevan
>>> --------------------------------------------------------------------- To
>>> unsubscribe, e-mail: gene...
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message