Not sure how to articulate my thoughts here. First, it's not about competing against Felix, though you'll find in the ASF multiple competing products (Axis vs CXF to mention only this one) and the ASF has never stated as a goal that it would provide a coherent offer or anything like this.
The problem I have with Felix is really a branding problem. While *we* (as developers) very well know that all the subprojects of Felix are not tied to the Felix Framework itself, it's really difficult to spread this word around to non techies. The name Felix is often associated to the OSGi framework implementation itself, and it's kinda hard to remove this tie unless either the project or the framework change its name to something else. For example, the framework could be referred to as Apache Foo and other subprojects as Apache iPojo or Apache Karaf. I think it would help removing this tie. The other way around is possible too, rename the project to something else, and keep Apache Felix as referring to the framework itself (which might be even better, but slightly more difficult to actually achieve). I'm not sure there is a very easy way, but d...@felix.a.o would a better place to discuss that. Another thought that comes to my mind is that over the past years, the ASF has tried to dismantle umbrella projects when it makes sense: i.e. when one of the subproject has sufficient momentum to create a community on its own. ACE is another podling related to OSGi and AFAIK it implements the DeploymentAdmin OSGi spec. I also see Karaf as a possible TLP at some point. That would become a problem with Felix, as the communities are rather disjoint between the subprojects (not all, I do agree). Not sure what the good size for a TLP is and other members can join the discussion and provide feedback. I don't think felix is oversized right now, but it might become a problem if it goes too far. Given this proposal includes more than 20 committers and most of them are not felix committers, we'd need the incubator for building up this community anyway. And btw, as any other incubator proposal, everyone interested is free to join the proposal and we would particularly welcome any felix committer here. That said, Aries wants to focus on application focused enterprise OSGi specs, which I do agree, could fit in the Felix scope, as could Ace do too. I guess in all cases, things can be discussed at the time the podling will graduate out of the incubator. The current goal is to aim to TLP as we think the size of the project can back that, but this is not written in stone. On Tue, Sep 1, 2009 at 17:03, Richard S. Hall <he...@ungoverned.org> wrote: > The Apache Felix project, since its inception, has been intended to host > implementations of the OSGi specifications, which includes both the > framework as well as other standard services. A framework implementation was > just one of the goals. > > This proposal seems to be saying a separate project is needed to create > some illusion of independence from Apache Felix, but the whole point of OSGi > is to be vendor neutral, so I am not sure I follow the rationale. Apache > Felix subprojects are not tied to the Apache Felix framework subproject and > by us pretending that they are, it only serves to perpetuate this myth. > > I have no issues with new efforts around and on top of OSGi being > incubated, but it gets a little trickier when we are talking about > implementing standard OSGi specs which was the intended community goal of > the Apache Felix project. Are we supposed to compete now for standard > service implementations? Or come to some sort of cartel-like agreement about > who gets what? > > -> richard > > > On 9/1/09 10:38, Jeremy Hughes wrote: > >> Hi, we would like to propose a new incubator podling called Aries. >> >> http://wiki.apache.org/incubator/AriesProposal >> >> Here is a quick summary of the proposal >> >> The Aries project will deliver a set of pluggable Java components >> enabling an enterprise OSGi application programming model. This >> includes implementations and extensions of application-focused >> specifications defined by the OSGi Alliance Enterprise Expert Group >> (EEG) and an assembly format for multi-bundle applications, for >> deployment to a variety of OSGi based runtimes. >> >> Aries aims to build a community of developers interested in the >> definition and delivery of software components that support an >> enterprise OSGi programming model and which can be integrated into a >> number of different runtime environments. >> >> We appreciate any feedback and comments on the proposal. >> >> Here is a plain text copy of the whole proposal: >> >> Apache Aries >> Abstract >> >> The Aries project will deliver a set of pluggable Java components >> enabling an enterprise OSGi application programming model. This >> includes implementations and extensions of application-focused >> specifications defined by the OSGi Alliance Enterprise Expert Group >> (EEG) and an assembly format for multi-bundle applications, for >> deployment to a variety of OSGi based runtimes. >> Proposal >> >> 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. >> >> Aries will offer an enterprise OSGi application programming model that >> enables applications to leverage Java EE and other enterprise >> technologies and to benefit from the modularity, dynamism and >> versioning capabilities of OSGi. A significant feature of Aries will >> be a container for OSGi Blueprint components - an implementation of >> the new OSGi v4.2 Blueprint component model that defines a standard >> dependency injection mechanism for Java components, which is derived >> from the Spring framework and extended for OSGi to declaratively >> register component interfaces as services in the OSGi service >> registry. >> >> In addition, the Aries project will develop a model for assembling an >> application/subsystem into a deployable unit, consisting of multiple >> bundles, as an archive which may include metadata that describes the >> version and external location of the application's constituent bundles >> or which may contain the bundles directly. >> >> The Aries project will deliver run-time componentry that supports >> applications, running in an OSGi framework, exploiting enterprise Java >> technologies common in web applications and integration scenarios >> including web application bundles, remote services integration and >> JPA. 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. The >> project will develop extensions that go beyond the OSGi EEG >> specifications to provide a more complete integration of OSGi >> modularity with Java enterprise technologies, in particular delivering >> support that includes but is not restricted to: >> >> * isolated enterprise applications composed of multiple, versioned >> bundles with dynamic lifecycle. >> * declarative transactions and security for Blueprint components >> * Container-managed JPA for Blueprint components >> * Message-driven Blueprint components >> * Configuration of resource references in module blueprints. >> * Annotation-based Blueprint configuration >> * Federation of lookup mechanisms between local JNDI and the OSGi >> service registry. >> * Fully declarative application metadata to enable reflection of >> an SCA component type definition. >> >> In order to maximise the potential scope of Aries adoption it is >> anticipated the project will remain agnostic of a number of >> complementary technologies and projects. It is the expectation that >> Aries will therefore not be delivering components such as: an >> application or integration server runtime kernel; a persistence >> provider; distribution provider; a deployment provider or a Web >> container. Aries will instead seek to enable the use of such >> components from other projects. >> Background >> >> OSGi is a mature and Java modularity technology that is well-used in >> many environments but, in the enterprise space, has more typically >> been exploited by the internals of the runtime infrastructure than the >> applications that run on it. This is primarily because of a lack of a >> clear enterprise OSGi application programming model and implementation >> of OSGi-enabled Java technology to support enterprise applications. >> OSGi specifications are specified and maintained by the OSGi Alliance >> which recognized this state of affairs several years ago and >> established the Enterprise Expert Group within the Alliance to focus >> specifically on the needs of enterprise applications. The objective of >> this project is to deliver open source implementations of these >> application-centric technologies to enable the development of >> application components, benefiting from the modularity of OSGi >> combined with standards-based programming models, which can be >> deployed to a variety of target runtimes. >> Rationale >> >> Aries aims to build a community of developers interested in the >> delivery of software components that support an enterprise OSGi >> programming model and which can be integrated into a number of >> different runtime environments. Apache hosts the Felix project which >> provides an OSGi framework implementation and a variety of projects >> which provide technologies exploited by enterprise application >> components as well as projects which provide runtimes to host >> application components. There is currently no Apache project focussed >> on OSGi enterprise applications that is independent from both the OSGi >> framework and the enterprise runtime environment in which application >> components are hosted. By maintaining independence of both the target >> runtime and underlying OSGi framework it is our intention to build the >> broadest possible community of developers for Aries, and to maximize >> the potential environments where Aries componentry can be used. >> Initial Goals >> >> We will initially focus on the Blueprint container and extend this >> with enterprise features such as support for container managed JPA and >> container managed transactions. Another initial focus area will be the >> contribution of code to support the assembly of isolated, multi-bundle >> applications that can be deployed as a unit. >> Current Status >> Meritocracy >> >> The Aries contributors recognize the desirability of running the >> project as a meritocracy. We are eager to engage other members of the >> community and operate to the standard of meritocracy that Apache >> emphasizes; we believe this is the most effective method of growing >> our community and enabling widespread adoption. >> Community >> >> OSGi is a mature Java modularity technology that is well-used in many >> environments but, in the enterprise space, has more typically been >> exploited by the internals of the runtime infrastructure than the >> applications that run on it. This is primarily because of a lack of a >> clear enterprise OSGi application programming model and implementation >> of OSGi-enabled Java technology to support enterprise applications. >> There is a need for open source implementations of these technologies >> and there is currently no Apache project focused on the wider goal of >> delivering components for an enterprise OSGi application programming >> model. Aries aims to build a community of developers interested in the >> definition and delivery of software components that support an >> enterprise OSGi programming model and which can be integrated into a >> number of different runtime environments. By maintaining independence >> of both the target runtime and underlying OSGi framework it is our >> intention to build the broadest possible community of developers. >> Alignment >> >> The purpose of Aries is to develop implementations of >> application-centric enterprise OSGi technologies that run on an OSGi >> framework, but not a specific one, and are used by application >> components deployed into a variety of runtime environments without >> being tied to any specific environment. 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 and enterprise application server >> and integration bus technologies, all of which exist as open source >> efforts within Apache and elsewhere. We expect, for example, that some >> code developed in Aries will run directly on top of an OSGi framework >> such as Felix and that applications exploiting Aries technologies >> could be deployed to runtimes such as ServiceMix and Geronimo. >> Avoiding the Warning Signs >> Orphaned products >> >> The contributors are leading vendors of OSGi-based technologies and >> have a long standing in the OSGi Alliance whose application-centric >> specifications this project will implement. There is minimal risk of >> this work becoming non-strategic and the contributors are confident >> that a larger community will form within the project in a relatively >> short space of time. >> Inexperience with Open Source >> >> Many of the committers have experience working in one or more open >> source projects including Apache Geronimo, Felix, ServiceMix, OpenEJB, >> and CXF. >> >> Homogeneous Developers >> >> The list of initial committers, geographically distributed across the >> U.S. and Europe, consists of developers from two companies - IBM and >> Progress software - with similar goals but for different scenarios. >> Many of these developers are experienced Apache committers already and >> all are experienced with working in distributed development >> communities. It is our hope that, through the incubator, further >> contributors with a broad background of experience but common interest >> in enterprise OSGi technologies will become involved with this >> project. >> >> Relationships with Other Apache Projects >> >> Aries will have a potential relationship with the Apache projects >> listed in this section. These projects all serve different purposes >> from Aries and have their own communities. It is hoped that each of >> these communities will become involved with Aries and help to build a >> diverse but independent Aries community. >> >> Apache Felix Karaf - >> http://felix.apache.org/site/apache-felix-karaf.html Apache Felix >> Karaf is an OSGi based runtime which provides a lightweight container >> onto which various components and applications can be deployed. It is >> related to Aries: >> >> 1. as a target OSGi based runtime to which Aries applications can >> be deployed. In this role, Karaf is a consumer of Aries technology. >> >> Apache Felix - http://felix.apache.org/site/index.html Apache >> Felix is primarily a core OSGi framework implementation. It is related >> to Aries: >> >> 1. as an underlying OSGi framework implementation and potentially >> other extensions that can be used both by Aries run-time components >> and the applications which use them. >> >> Apache Geronimo - http://geronimo.apache.org/ Apache Geronimo is >> a server runtime framework and fully certified Java EE 5 application >> server runtime. It is related to Aries in two ways: >> >> 1. as a target runtime to which Aries applications can be deployed. >> In this role, Geronimo is a consumer of Aries technology. >> 2. the Geronimo blueprint sandbox - >> http://svn.apache.org/repos/asf/geronimo/sandbox/blueprint/ - contains >> an implementation of the OSGi Blueprint container which will be moved >> to Aries. >> >> Apache Tuscany - http://tuscany.apache.org/ Apache Tuscany >> provides a comprehensive infrastructure for SOA development and >> management that is based on Service Component Architecture (SCA) >> standard. It can be a consumer of Aries technology to provide an Aries >> SCA implementation type for composing Aries applications in coarse >> grained and potentially heterogeneous service assemblies. >> >> Apache CXF - http://cxf.apache.org/ Apache CXF provides a Java >> Web Services framework for distributed computing and remote service >> realization and invocation using API's such as JAX-WS and JAX-RS. It >> also provides the OSGi Remote Services (OSGi RFC 119) reference >> implementation in a subproject: >> http://cxf.apache.org/distributed-osgi.html. It is related to Aries in >> the following way: >> >> 1. As Remote Services is a significant Enterprise specification >> being produced by the EEG, it is expected that consumers of Aries will >> be looking for an implementation of this specification. CXF provides >> an implementation of this specification which already has a >> significant active community. The Aries project will make it easy for >> Aries consumers to consume the CXF Remote Services implementation, >> possibly by providing an instance of the application model that >> references the CXF Remote Services implementation. This would mean >> that end users will seamlessly pull in the required components from >> CXF by using the Aries-provided definition. >> >> Apache ServiceMix - http://servicemix.apache.org/ Apache >> ServiceMix provides an ESB that combines the functionality of a >> Service Oriented Architecture (SOA) and Event Driven Architecture >> (EDA) to create an agile ESB. ServiceMix runs on OSGi and was the >> source of the Apache Felix Karaf runtime. It can be a consumer of >> Aries applications and associated componentry as a natural evolution >> of its existing Karaf "feature" usage. >> >> Apache OpenJPA - http://openjpa.apache.org/ Apache OpenJPA is a >> Java persistence project. It is related to Aries as a JPA persistence >> provider, including entity scanning and enhancement. The Aries project >> will make it easy for JPA persistence providers such as OpenJPA to be >> used in an OSGi environment and will provide container managed >> persistence for the Blueprint container. >> >> Documentation >> >> An early draft of OSGi v4.2 core and compendium specifications - which >> includes the Blueprint container specification - is available at: >> http://www.osgi.org/download/osgi-4.2-early-draft3.pdf >> Initial Source >> >> * The Blueprint container impl from the Geronimo sandbox will be >> moved to the Aries project for further development: >> http://svn.apache.org/repos/asf/geronimo/sandbox/blueprint >> * IBM will also contribute code for: >> o container-managed JPA support in an OSGi environment. >> o making OSGi services visible to Java EE components through >> JNDI. >> o packaging web components as bundles and a URL handler for >> recognizing and converting non-bundled Web components >> * We will also be soliciting implementations of other OSGi >> enterprise application-centric specifications. >> >> External Dependencies >> >> * Apache Ant http://ant.apache.org Apache License >> * Apache Commons http://commons.apache.org Apache License >> * Junit (Java unit test framework) http://junit.sourceforge.net CPL >> v1.0 license: http://junit.sourceforge.net/cpl-v10.html >> * Apache Felix (implementation of the OSGi Core and Compendium >> specifications - compliance level unknown) http://felix.apache.org >> Apache License (hosted by ASF). >> * Eclipse Equinox (compliant implementation of the OSGi Core >> Specification and Compendium specifications) >> http://eclipse.org/equinox/ Eclipse Public License >> * OpenJPA http://openjpa.apache.org Apache License >> * Serp http://serp.sourceforge.net/ BSD >> * Apache Geronimo http://geronimo.apache.org Apache License >> >> Required Resources >> Mailing lists >> >> aries-private (with moderated subscriptions) >> aries-dev >> aries-commits >> aries-user >> >> Subversion Directory >> >> http://svn.apache.org/repos/asf/incubator/aries >> >> Issue Tracking >> >> JIRA (ARIES) >> >> Web Site >> >> Confluence (Aries) >> >> Initial Committers >> >> Names of initial committers with affiliation and current ASF status: >> >> * Alasdair Nottingham (IBM) >> * Andrew Osborne (IBM) >> * Dan Kulp (Progress, ASF member) >> * David Bosschaert (Progress, ASF committer) >> * David Jencks (IBM, ASF member) >> * Eoghan Glynn (Progress, ASF committer) >> * Graham Charters (IBM) >> * Guillaume Nodet (Progress, ASF member) >> * Hiram Chirino (Progress, ASF member) >> * Ian Robinson (IBM) >> * James Strachan (Progress, ASF member) >> * Jarek Gawor (IBM, ASF member) >> * Jeremy Hughes (IBM, ASF committer) >> * Joe Bohn (IBM, ASF committer) >> * Lin Sun (IBM, ASF committer) >> * Mark Nuttall (IBM) >> * Oisin Hurley (Progress) >> * Rick McGuire (IBM, ASF committer) >> * Sergey Beryozkin (Progress, ASF committer), >> * Timothy Ward (IBM) >> * Valentin Mahrwald (IBM) >> * Zoe Slattery (IBM) >> >> Affiliations >> >> The majority of the initial committers are employed by IBM corp or >> Progress Software. One objective of the incubator is to attract a >> diverse community of contributors and we anticipate future >> contributors to have other affiliations. >> >> Sponsors >> Champions >> >> Kevan Miller, Guillaume Nodet >> >> Nominated Mentors >> >> Guillaume Nodet, Davanum Srinivas (Dims) >> >> Sponsoring Entity >> >> The incubator. Successful graduation from Incubator should result in >> Aries becoming a new TLP. >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
