incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject Re: [PROPOSAL] Apache Aries incubator for Enterprise OSGi
Date Wed, 02 Sep 2009 15:58:14 GMT
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.
Having apache committers from a project be granted commit access to 
another project is not really a problem, as soon as the other project's 
PMC decide what are the "rules".

The new project can also be a Felix subproject, with specific commit 
access granted to a specific set of committers, if needed. I'm pretty 
sure that infra can deal with such a granularity. Also the felix PMC can 
check that the new committers are not committing in the other projects, 
if needed.

So far, this is how we did for FtpServer, SSHd and Vysper in MINA. In 
fact, Vysper is still in a sandbox, but I can see the moment where it 
will get out, either as a MINA subproject, or as a TLP. The biggest 
advantage is that, as all the committers were already working on other 
projects, and as the MINA PMC was able to check that the project was 
following the rules (IP, etc), it's far easier than going through 

I can see how better it could be for Aries to start as a felix 
subproject, for many reasons.
> 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...).
It would be better to see Felix as a OSGi aggregator (a bit like WS or 
DB are), with potentially many implementations. It would be so great if 
Buildr, Ant, Maven, Archiva, Continuum, were all embedded in a Build 
Tools project, instead of being one of the 70 TLP. From the user PoV, 
it's difficult to know what they all are doing.

This is a bit more general than just Felix, here. We have more than 70 
TLP, and this number will continue to grow in the next few years. Why 
can't we aggregate projects within categories at some point ?
> 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.
I'm not sure that because a project has non apache committers, it should 
be started in incubator, as soon as the TLP can "educate" the project. 
of course, if all the peope are non apache committers, that's a 
different story.

That being said, the best would be to first check for synergies, then 
think about creating the poddling if there are not too much overlap. Be 
pragmatic !

cordialement, regards,
Emmanuel L├ęcharny

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

View raw message