incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karl Pauls <>
Subject Re: [PROPOSAL] Apache Aries incubator for Enterprise OSGi
Date Wed, 02 Sep 2009 22:52:29 GMT
>From my perspective, the incubator isn't a loophole around the
meritocracy approach of existing TLPs. Submitting a couple of patches
can't be to high a barrier for people new to the ASF and the code

We regularly vote people in as committers if they contribute to felix
subprojects and typically, if we accept a larger piece of code as a
donation, we try to get the creator as a committer too. We did this
with Karaf recently.

I think felix is an excellent place for consolidating OSGi
spec-related development here at Apache since the community is in
place and very active.



On Wed, Sep 2, 2009 at 5:29 PM, Guillaume Nodet<> wrote:
> We have in this proposal a lot of people who are not felix committers and
> who are not even apache committers at all.
> They want to work on some code and create a community around it.  The way
> the ASF works means that the incubator is the right place to do so.  The
> only other solution is to develop it in a closed source environment and
> submit it at Apache when it's done, and i really don't think it's a good
> idea, given the willingness to do it in open source.
> The blueprint implementation has been developped so far inside the Geronimo
> TLP, part of the reason is that some of the people working on it were not
> felix committers, so it was way easier to work there instead of contributing
> patches until getting committership.    It is very difficult to commit to
> work on a new implementation of anything when you don't even have commit
> priviledges.  It's ok for patches, but not for a new dev.   That's what we
> have here.   We have people here wanting to work on some new OSGi spec
> implementation, and the only way for them to do so at Apache in to go into
> the incubator.
> Even, if Aries was to compete against Felix in any way, it's not a good
> enough argument.  We already have multiple projects in the ASF that do have
> overlap as it was pointed already multiple times in this thread: mutliple
> REST implementations, multiple JAX-WS implementations, etc...  But the Aries
> podling does not aim to even provide alternative implementation to what
> Felix already has, it's goal is to create a community with new people who
> want to work on that and deliver both implementations of new OSGi specs
> (such as blueprint and subsystems / applications, jpa ...) and also
> additional extensions (such as blueprint custom namespaces for transactions,
> etc...).
> For the independance, the only real place I know which provides OSGi
> components, not tainted with a given framework are SpringSource (though it's
> open source, the community is not really open) and OPS4J, but I do think
> it's a different discussion.
> I restate that the goal of the Aries proposal is to foster a community
> around some new code implementing some OSGi specs.  And I don't think we can
> do that inside an existing TLP, as we have non apache committers that want
> to create this code.  That's what the incubator has been created for.
> Last, accepting to create a podling does not mean the final destination of
> the podling is defined yet.   Aries could become either a TLP, a Felix
> subproject, or be split across the two of them.  The one that makes the most
> sense should prevail at graduation time.  By the time Aries is ready to
> graduate, the discussion about it's final destination will be held.  And
> that's where what you say will make sense and where your vote needs to be
> cast.
> I really do understand your concerns (even if I don't share them), but now
> is not the time to vote -1.
> On Wed, Sep 2, 2009 at 16:30, Richard S. Hall <> wrote:
>> I will try to keep this short.
>> The OSGi Service Platform is composed of the core and compendium specs. The
>> EEG specs are not in any way special and will ultimately end up as part of
>> the compendium spec. Apache Felix was incubated to build a community at
>> Apache around implementing the OSGi specs.
>> Now we are being told that this mission is too tainted because we implement
>> the framework spec, which is part of the core spec. I find this unfathomable
>> given the nature of OSGi and the efforts to which the Felix community goes
>> to be good OSGi citizens...we even allow for competing implementations
>> within our community.
>> It is also particularly odd, since the Equinox and Knopflerfish communities
>> are in the same situation, implementing both core and compendium specs with
>> their frameworks largely synonymous with their project name.
>> I am not naive enough to expect this discussion to change much, since I
>> imagine there has already been a fair amount of political calculation around
>> this proposal, otherwise the Felix community in general would have been
>> engaged earlier.
>> So, here's my vote:
>>   * -1 for the portion of the proposal creating yet another community
>>     for implementing OSGi specs at Apache since the Felix community
>>     would happily welcome more contribution (just like recently
>>     occurred with ServiceMix members being accepted as Felix
>>     committers and PMC members for the Karaf subproject)
>>   * +1 for the rest of the proposal to explore how to build an
>>     enterprise component model on OSGi and the other non-spec related
>>     topics.
>> -> richard
>> On 9/1/09 22:53, Kevan Miller wrote:
>>> On Sep 1, 2009, at 2:08 PM, Richard S. Hall wrote:
>>>  On 9/1/09 13:59, Martin Cooper wrote:
>>>>> On Tue, Sep 1, 2009 at 10:51 AM, Richard S. Hall<>
>>>>>  wrote:
>>>>> I'm not sure I understand the issue here. Whether Aries becomes its
>>>>> own TLP, or a sub-project of Felix or some other TLP, isn't relevant
>>>>> until the project is ready to exit incubation. Why does it warrant
>>>>> such apparently intense discussion before the project is even accepted
>>>> We are actually discussing something else. We are discussing the scope of
>>>> the proposal, which includes hosting OSGi standard service implementations,
>>>> which is part of Felix' scope.
>>>> If we are developing standard OSGi services within Apache, then Felix
>>>> provides an enthusiastic community to do this and there is no need to start
>>>> another incubator project for such a purpose. On the other hand, stuff like
>>>> "a set of pluggable Java components enabling an enterprise OSGi application
>>>> programming model" makes perfect sense to be incubated.
>>> Thanks for the clarification... So, your issue is mainly with "It is a
>>> goal of the Aries project to provide a natural home for open source
>>> implementations of current and future OSGi EEG specifications..."?
>>> Personally, I tend to think of Felix in terms of OSGi Core Platform. I
>>> certainly hadn't expected it to be the source for all OSGi standard
>>> implementations from Apache -- not for implementations of Enterprise Expert
>>> Group specs, anyway. I'm sure there are flaws with my perceptions...
>>> So, we have a group that is interested in working on an enterprise OSGi
>>> application programming model at Apache (including implementations of at
>>> least some EEG specifications). An incubator project would seem to be an
>>> excellent place for this work to start. Interested Felix community members
>>> would certainly be able to join this effort.
>>> It then becomes a question of, assuming successful incubation, where does
>>> the community graduate to? TLP, Felix subproject(s), or elsewhere. All
>>> successful outcomes, IMO.
>>> --kevan
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog:
> ------------------------
> Open Source SOA

Karl Pauls

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message