incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Offermans <>
Subject Re: [PROPOSAL] Apache Aries incubator for Enterprise OSGi
Date Tue, 01 Sep 2009 20:20:25 GMT
On Sep 1, 2009, at 16:38 , Jeremy Hughes wrote:

> It is a goal of the Aries project to provide a natural home for open
> source implementations of current and future OSGi EEG specifications,
> including the opportunity for the collaborative development of
> compliance tests, and an environment to demonstrate the composition of
> these technologies and to explore areas where EEG specifications lack
> coverage. A further goal of this project is to leverage experience
> gained from it to inform contributions to OSGi EEG requirements and
> specification documents.

Just reading this paragraph my initial reaction is that this is very  
much aligned with the Felix project. Felix's goals are basically to  
provide a full OSGi implementation of both the framework and  
compendium services whilst also providing a home for extensions to the  
specification that make sense. In that sense Aries sounds like a  
subset of Felix's goal, targetting the enterprise specifications.

> The Aries project will deliver run-time componentry that supports
> applications [...] The project is not expected to deliver a complete  
> application or
> integration server runtime but will instead deliver enterprise
> application componentry that can be integrated into such runtimes.

This makes a lot of sense. Any project building on a component  
architecture should be setup in such a way that many of the individual  
components can be combined and reused in different deployment scenarios.

> There is currently no Apache project focussed
> on OSGi enterprise applications that is independent from both the OSGi
> framework

This is a really interesting topic, and others have commented on this:  
the perception that bundles in the Felix project only run on Felix. Of  
course anybody who makes an effort to understand OSGi quickly learns  
that the whole purpose of the spec is to have bundles that can run on  
any implementation and from years of experience of doing OSGi  
projects, I must say that every project I did, did in fact use bundles  
from Felix, Knopflerfish, Eclipse, Pax, various other sources as well  
as project specific bundles.

My view is that we should really try to fix this misconception instead  
of using it as a reason to start new projects.

> For this reason we believe
> Aries is a project whose community would be best served if it could
> leverage but be independent from the communities that provide
> underlying OSGi framework technology

If you look at the OSGi specification as a whole, it consists of two  
parts: the framework and the compendium. In fact, with the different  
expert groups, you could say there is more than one compendium as each  
expert group usually adds a compendium of their own. Anyway, OSGi is  
more than just the framework alone, and Felix already supplies an  
implementation of the whole spec, so there currently is no community  
that provide just the OSGi framework (also look at Knopflerfish and  
Equinox, both of which also provide compendium implementations).

> Relationships with Other Apache Projects

I know ACE is only in incubation, but is there a reason for not  
mentioning it in this list? To me it makes sense to also consider  
technology to deploy and update OSGi components and I think ACE could  
fit in there nicely.

> The incubator. Successful graduation from Incubator should result in
> Aries becoming a new TLP.

As others mentioned, this is perhaps an issue that should be addressed  
when leaving the incubator. As I explained above, my personal view is  
that this would fit nicely within the Felix TLP, especially since  
there seems to be a lot of focus on implementing the OSGi Enterprise  
"compendium" which is part of the OSGi specifications. On the other  
hand, if you guys really want to work outside of Felix then of course  
that's an option too. I do think it's great that there is a group of  
people wanting to implement these enterprise specs and explore related  
options! Let's just try and leverage each others' work as much as  

Greetings, Marcel

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