Jeremy Hughes wrote:
2009/9/16 Jim Jagielski <j...@jagunet.com>:
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
missing?
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
project.
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
