incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Stoddard <>
Subject Re: [VOTE] Accept Aries proposal for incubation
Date Thu, 17 Sep 2009 17:27:09 GMT
Jeremy Hughes wrote:
> 2009/9/16 Jim Jagielski <>:
>> On Sep 16, 2009, at 4:32 AM, Niall Pemberton wrote:
> ...
>>> IMO this is more a graduation issue, rather than something that should
>>> prevent entry to the incubator - since thats when destination is
>>> decided. There are many possible outcomes from that - perhaps some
>>> parts will go to felix and others to a new TLP(s) - but I say lets see
>>> how it works out during graduation rather than shooting it down now.
>> I agree that the rubber hits the road when graduation, and when there
>> is a resolution before the board to make this a TLP. However, my
>> thoughts are that without this concern front-and-center from the get-go,
>> the podling runs the risk of hitting this roadblock right at the end,
>> at which point who knows how much impact this may have on it... In other
>> words, if a podling umbrella attempts to graduate into a TLP umbrella, it
>> will likely be shot down. Do we really want to wait until the end to
>> address this once and for all?
>> Just my 2c.
>> PS: BTW, I think it's a great proposal and podling and technically am a big
>>    +1 on it. My only concern is lack of directed focus...
> It is not our intent to create an umbrella TLP - the focus of Aries is
> specifically on developing the componentry needed to enable an
> enterprise OSGi application prgramming model. This will include
> implementing some of the OSGi EEG specs - the initial focus is as
> described in the sections "Initial Goals" and "Initial Source" but the
> proposal also tries to make it clear that Aries will consume
> technology from other projects where available: "It is the expectation
> that Aries will therefore not be delivering components such as ...
> Aries will instead seek to enable the use of such components from
> other projects."
> We are starting out largely speaking as a community of people with a
> heritage in enterprise Java runtimes looking to encouarge the
> exploitation of OSGi by the applications deployed to enterprise
> environments. We are not looking to target specific runtimes or to
> implement *every* spec that comes out of the EEG but we are looking to
> build coherent componentry needed by enterprise applications when
> deployed as OSGi bundles to an enterprise runtime. We've described
> this in the "Relationship with Other Apache Projects" section. How we
> evolve from the stated "initial goals" will largely depend on the
> community that forms - which I believe is reasonable for a new
> incubator.
> To help remove any impression that Aries is looking to become an
> umbrella TLP we could perhaps reword the first sentence of the
> proposal from
> "It is a goal of the Aries project to provide a natural home for open
> source implementations of current and future OSGi EEG specifications,
> .."
> to
> "It is a goal of the Aries project to implement OSGi EEG
> specifications that are part of the enterprise application programming
> model, ...."
> to clarify the scope - this remains consistent with the rest of the proposal.
> Thanks,
> Jeremy

Crickets it's terribly quiet around here..

I am having a really difficult time getting my head around Jim and 
Niclas' objections that this is an umbrella project.  The mother of all 
umbrella projects was Jakarta... (coded in Java? It should go into 
Jakarta...); this proposal clearly isn't that.  This proposal is 
concerned with implementing an OSGi application programming model; it 
relies heavily on specs from the OSGi Alliance Enterprise Expert Group 
(EEG) and the EEG itself is a small, narrowly scoped part of the OSGi 
Alliance.  The project scope seems pretty darn succinct to me. What am I 

What I see here is a surprisingly diverse group of developers interested 
in working on a project and having the freedom to bring the vision to 
fruition.  A lot like Geronimo really, whose mission is to implement the 
JEE programming model.  Geronimo draws heavily on projects from both 
inside and outside the ASF.  If the Geronimo team requires a piece of 
technology that's not available, they collaborate with other groups to 
obtain it or do the work themselves at last resort.   In other words, 
Geronimo has operational freedom to control its own destiny.  Not a bad 
thing, imho.  It's pretty clear (at least to me :-) that the Aries 
proposal is more tightly scoped than even Geronimo and Geronimo works 
reasonably well. 

The project proposers clearly know -where- they want to go (and have 
communicated that in the proposal) .. what's understandably less clear 
is precisely how they are going to get there... that's why a degree of 
operational freedom is important; attempting to nail the proposers down 
to a precise path right now is counter productive to the success of the 


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

View raw message