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 Wed, 02 Sep 2009 14:30:23 GMT
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

-> 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:

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