[jira] Created: (INCUBATOR-105) Typos in some top-level pages
Typos in some top-level pages - Key: INCUBATOR-105 URL: https://issues.apache.org/jira/browse/INCUBATOR-105 Project: Incubator Issue Type: Improvement Components: site Reporter: Mark Hindess Priority: Trivial I spotted a number of typos while reviewing some material on the Incubator web site. I will attach a patch shortly. I also note that many of the documents in ip-clearance contain the typo: a Corporate CLA is recorded if such is is required with a spurious duplicate is. I've not fixed these in my patch as I didn't want to modify them without knowing how to fix the common ancestor of these pages. I've only reviewed the top-level pages not those in the projects tree. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[jira] Updated: (INCUBATOR-105) Typos in some top-level pages
[ https://issues.apache.org/jira/browse/INCUBATOR-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Hindess updated INCUBATOR-105: --- Attachment: minor.spelling.fixes.diff Typos in some top-level pages - Key: INCUBATOR-105 URL: https://issues.apache.org/jira/browse/INCUBATOR-105 Project: Incubator Issue Type: Improvement Components: site Reporter: Mark Hindess Priority: Trivial Attachments: minor.spelling.fixes.diff I spotted a number of typos while reviewing some material on the Incubator web site. I will attach a patch shortly. I also note that many of the documents in ip-clearance contain the typo: a Corporate CLA is recorded if such is is required with a spurious duplicate is. I've not fixed these in my patch as I didn't want to modify them without knowing how to fix the common ancestor of these pages. I've only reviewed the top-level pages not those in the projects tree. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[VOTE] Accept Aries proposal for incubation
The Aries proposal thread has now gone quiet and we would like to call a vote to accept Aries into the Incubator. There has been some good discussion with a few changes to the proposal including the addition of initial committers, increasing the diversity of committers from the start. The proposal is included below and is also at: http://wiki.apache.org/incubator/AriesProposal Please cast your votes: [ ] +1 Accept Aries for incubation [ ] +0 Indifferent to Aries incubation [ ] -1 Reject Aries for incubation (please help us understand why) Thank you. -- 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
Re: [VOTE] Accept Aries proposal for incubation
+1 Accept Aries for incubation -- dims On 09/15/2009 11:54 AM, Jeremy Hughes wrote: The Aries proposal thread has now gone quiet and we would like to call a vote to accept Aries into the Incubator. There has been some good discussion with a few changes to the proposal including the addition of initial committers, increasing the diversity of committers from the start. The proposal is included below and is also at: http://wiki.apache.org/incubator/AriesProposal Please cast your votes: [ ] +1 Accept Aries for incubation [ ] +0 Indifferent to Aries incubation [ ] -1 Reject Aries for incubation (please help us understand why) Thank you. -- 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
Re: [VOTE] Accept Aries proposal for incubation
+1 Craig On Sep 15, 2009, at 8:54 AM, Jeremy Hughes wrote: The Aries proposal thread has now gone quiet and we would like to call a vote to accept Aries into the Incubator. There has been some good discussion with a few changes to the proposal including the addition of initial committers, increasing the diversity of committers from the start. The proposal is included below and is also at: http://wiki.apache.org/incubator/AriesProposal Please cast your votes: [ ] +1 Accept Aries for incubation [ ] +0 Indifferent to Aries incubation [ ] -1 Reject Aries for incubation (please help us understand why) Thank you. -- 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
Re: [VOTE] Accept Aries proposal for incubation
+1 ...ant On Tue, Sep 15, 2009 at 4:54 PM, Jeremy Hughes hugh...@apache.org wrote: The Aries proposal thread has now gone quiet and we would like to call a vote to accept Aries into the Incubator. There has been some good discussion with a few changes to the proposal including the addition of initial committers, increasing the diversity of committers from the start. The proposal is included below and is also at: http://wiki.apache.org/incubator/AriesProposal Please cast your votes: [ ] +1 Accept Aries for incubation [ ] +0 Indifferent to Aries incubation [ ] -1 Reject Aries for incubation (please help us understand why) Thank you. -- 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
Re: [VOTE] Accept Aries proposal for incubation
+1 Dan On Tue September 15 2009 11:54:10 am Jeremy Hughes wrote: The Aries proposal thread has now gone quiet and we would like to call a vote to accept Aries into the Incubator. There has been some good discussion with a few changes to the proposal including the addition of initial committers, increasing the diversity of committers from the start. The proposal is included below and is also at: http://wiki.apache.org/incubator/AriesProposal Please cast your votes: [ ] +1 Accept Aries for incubation [ ] +0 Indifferent to Aries incubation [ ] -1 Reject Aries for incubation (please help us understand why) Thank you. -- 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
Re: [VOTE] Accept Aries proposal for incubation
+1 On Tue, Sep 15, 2009 at 6:24 PM, Daniel Kulp dk...@apache.org wrote: +1 Dan On Tue September 15 2009 11:54:10 am Jeremy Hughes wrote: The Aries proposal thread has now gone quiet and we would like to call a vote to accept Aries into the Incubator. There has been some good discussion with a few changes to the proposal including the addition of initial committers, increasing the diversity of committers from the start. The proposal is included below and is also at: http://wiki.apache.org/incubator/AriesProposal Please cast your votes: [ ] +1 Accept Aries for incubation [ ] +0 Indifferent to Aries incubation [ ] -1 Reject Aries for incubation (please help us understand why) Thank you. -- 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
Re: [VOTE] Accept Aries proposal for incubation
+1 --kevan On Sep 15, 2009, at 11:54 AM, Jeremy Hughes wrote: The Aries proposal thread has now gone quiet and we would like to call a vote to accept Aries into the Incubator. There has been some good discussion with a few changes to the proposal including the addition of initial committers, increasing the diversity of committers from the start. The proposal is included below and is also at: http://wiki.apache.org/incubator/AriesProposal Please cast your votes: [ ] +1 Accept Aries for incubation [ ] +0 Indifferent to Aries incubation [ ] -1 Reject Aries for incubation (please help us understand why) Thank you. -- 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
Re: [VOTE] Accept Aries proposal for incubation
+1 2009/9/15 Jeremy Hughes hugh...@apache.org: The Aries proposal thread has now gone quiet and we would like to call a vote to accept Aries into the Incubator. There has been some good discussion with a few changes to the proposal including the addition of initial committers, increasing the diversity of committers from the start. The proposal is included below and is also at: http://wiki.apache.org/incubator/AriesProposal Please cast your votes: [ ] +1 Accept Aries for incubation [ ] +0 Indifferent to Aries incubation [ ] -1 Reject Aries for incubation (please help us understand why) Thank you. -- 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
Re: [VOTE] Accept Aries proposal for incubation
+1 On Tuesday, September 15, 2009, Jeremy Hughes hugh...@apache.org wrote: The Aries proposal thread has now gone quiet and we would like to call a vote to accept Aries into the Incubator. There has been some good discussion with a few changes to the proposal including the addition of initial committers, increasing the diversity of committers from the start. The proposal is included below and is also at: http://wiki.apache.org/incubator/AriesProposal Please cast your votes: [ ] +1 Accept Aries for incubation [ ] +0 Indifferent to Aries incubation [ ] -1 Reject Aries for incubation (please help us understand why) Thank you. -- 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
Re: [VOTE] Accept Aries proposal for incubation
+1 Regards, Alan On Sep 15, 2009, at 8:54 AM, Jeremy Hughes wrote: The Aries proposal thread has now gone quiet and we would like to call a vote to accept Aries into the Incubator. There has been some good discussion with a few changes to the proposal including the addition of initial committers, increasing the diversity of committers from the start. The proposal is included below and is also at: http://wiki.apache.org/incubator/AriesProposal Please cast your votes: [ ] +1 Accept Aries for incubation [ ] +0 Indifferent to Aries incubation [ ] -1 Reject Aries for incubation (please help us understand why) Thank you. -- 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
Re: [VOTE] Accept Aries proposal for incubation
+1 Accept Aries for incubation -- Luciano Resende http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Accept Aries proposal for incubation
+1 Accept Aries for incubation Carsten -- Carsten Ziegeler cziege...@apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Accept Aries proposal for incubation
+1 Jeremy Hughes wrote: The Aries proposal thread has now gone quiet and we would like to call a vote to accept Aries into the Incubator. There has been some good discussion with a few changes to the proposal including the addition of initial committers, increasing the diversity of committers from the start. The proposal is included below and is also at: http://wiki.apache.org/incubator/AriesProposal Please cast your votes: [ ] +1 Accept Aries for incubation [ ] +0 Indifferent to Aries incubation [ ] -1 Reject Aries for incubation (please help us understand why) Thank you. -- 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
Re: [VOTE] Accept Aries proposal for incubation
On Tue, Sep 15, 2009 at 5:54 PM, Jeremy Hughes hugh...@apache.org wrote: Please cast your votes: +1 /niklas - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Accept Aries proposal for incubation
On Sep 15, 2009, at 11:54 AM, Jeremy Hughes wrote: The Aries proposal thread has now gone quiet and we would like to call a vote to accept Aries into the Incubator. There has been some good discussion with a few changes to the proposal including the addition of initial committers, increasing the diversity of committers from the start. The proposal is included below and is also at: http://wiki.apache.org/incubator/AriesProposal Please cast your votes: [ ] +1 Accept Aries for incubation [ ] +0 Indifferent to Aries incubation [ ] -1 Reject Aries for incubation (please help us understand why) After much thought, I am voting -1 for 1 main reason. 1: From the get-go, this appears headed towards an umbrella project. Too many ways to justify yeah, this belongs here and far too few ways to justify nope, this doesn't quite fit in. So whether TLP or part of Felix (as was the discussion), this appears too comprehensive. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[jira] Commented: (INCUBATOR-105) Typos in some top-level pages
[ https://issues.apache.org/jira/browse/INCUBATOR-105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12755678#action_12755678 ] Niall Pemberton commented on INCUBATOR-105: --- Looks like I don't have permission to resolve this issue - but I have applied your patch, thanks!! http://svn.apache.org/viewvc?view=revrevision=815467 Typos in some top-level pages - Key: INCUBATOR-105 URL: https://issues.apache.org/jira/browse/INCUBATOR-105 Project: Incubator Issue Type: Improvement Components: site Reporter: Mark Hindess Priority: Trivial Attachments: minor.spelling.fixes.diff I spotted a number of typos while reviewing some material on the Incubator web site. I will attach a patch shortly. I also note that many of the documents in ip-clearance contain the typo: a Corporate CLA is recorded if such is is required with a spurious duplicate is. I've not fixed these in my patch as I didn't want to modify them without knowing how to fix the common ancestor of these pages. I've only reviewed the top-level pages not those in the projects tree. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Accept Aries proposal for incubation
+1 Niall On Tue, Sep 15, 2009 at 4:54 PM, Jeremy Hughes hugh...@apache.org wrote: The Aries proposal thread has now gone quiet and we would like to call a vote to accept Aries into the Incubator. There has been some good discussion with a few changes to the proposal including the addition of initial committers, increasing the diversity of committers from the start. The proposal is included below and is also at: http://wiki.apache.org/incubator/AriesProposal Please cast your votes: [ ] +1 Accept Aries for incubation [ ] +0 Indifferent to Aries incubation [ ] -1 Reject Aries for incubation (please help us understand why) Thank you. -- 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
Re: [VOTE] Accept Aries proposal for incubation
+1 Donald Jeremy Hughes wrote: The Aries proposal thread has now gone quiet and we would like to call a vote to accept Aries into the Incubator. There has been some good discussion with a few changes to the proposal including the addition of initial committers, increasing the diversity of committers from the start. The proposal is included below and is also at: http://wiki.apache.org/incubator/AriesProposal Please cast your votes: [ ] +1 Accept Aries for incubation [ ] +0 Indifferent to Aries incubation [ ] -1 Reject Aries for incubation (please help us understand why) Thank you. -- 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
Re: [VOTE] Accept Aries proposal for incubation
+1 Joe Bohn Jeremy Hughes wrote: The Aries proposal thread has now gone quiet and we would like to call a vote to accept Aries into the Incubator. There has been some good discussion with a few changes to the proposal including the addition of initial committers, increasing the diversity of committers from the start. The proposal is included below and is also at: http://wiki.apache.org/incubator/AriesProposal Please cast your votes: [ ] +1 Accept Aries for incubation [ ] +0 Indifferent to Aries incubation [ ] -1 Reject Aries for incubation (please help us understand why) Thank you. -- 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
Re: [VOTE] Accept Aries proposal for incubation
[x] +1 Accept Aries for incubation Cheers Daniel On Tue, Sep 15, 2009 at 5:54 PM, Jeremy Hughes hugh...@apache.org wrote: The Aries proposal thread has now gone quiet and we would like to call a vote to accept Aries into the Incubator. There has been some good discussion with a few changes to the proposal including the addition of initial committers, increasing the diversity of committers from the start. The proposal is included below and is also at: http://wiki.apache.org/incubator/AriesProposal Please cast your votes: [ ] +1 Accept Aries for incubation [ ] +0 Indifferent to Aries incubation [ ] -1 Reject Aries for incubation (please help us understand why) Thank you. -- 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
Re: [VOTE] Accept Aries proposal for incubation
On Tue, Sep 15, 2009 at 9:07 PM, Jim Jagielski j...@jagunet.com wrote: After much thought, I am voting -1 for 1 main reason. 1: From the get-go, this appears headed towards an umbrella project. Too many ways to justify yeah, this belongs here and far too few ways to justify nope, this doesn't quite fit in. So whether TLP or part of Felix (as was the discussion), this appears too comprehensive. This comment surprised me enough to read this proposal again, and I have to agree with Jim. On one hand, the proposal starts out to speak of current and future EEG specifications, but then becomes very blur of what that really means. Components, not solutions, not a server, not a framework, but components could as Jim points out mean everything (or at least anything one can stick in a Bundle in OSGi lingo). Does it warrants a -1? Yes, I think it does. But considering how many PMC members are on the roster, I doubt it will stop anything. -1 from me, until I see a limitation in scope that is describable... I like the intent, but not the formulation. Look at your current plans, distill the essence and put that in the proposal. Cheers -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Accept Aries proposal for incubation
On Sep 15, 2009, at 8:54 AM, Jeremy Hughes wrote: The Aries proposal thread has now gone quiet and we would like to call a vote to accept Aries into the Incubator. There has been some good discussion with a few changes to the proposal including the addition of initial committers, increasing the diversity of committers from the start. The proposal is included below and is also at: http://wiki.apache.org/incubator/AriesProposal Please cast your votes: [ ] +1 Accept Aries for incubation [ ] +0 Indifferent to Aries incubation [ ] -1 Reject Aries for incubation (please help us understand why) +1 Ralph - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release cassandra 0.4.0-rc2
On Fri, Sep 11, 2009 at 10:14 AM, Eric Evans eev...@rackspace.com wrote: The Cassandra community voted on and approved the release of Apache Cassandra 0.4.0-rc2. We would now like to request the approval of the Incubator PMC for this release. Cassandra is a massively scalable, eventually consistent, distributed, structured key-value store. Podling vote thread: http://www.mail-archive.com/cassandra-...@incubator.apache.org/msg00887.html 0.4.0-rc2 artifacts: http://people.apache.org/~eevans SVN tag: https://svn.apache.org/repos/asf/incubator/cassandra/tags/cassandra-0.4.0-rc2 Project home: http://incubator.apache.org/cassandra/ Incubation status: http://incubator.apache.org/projects/cassandra.html The vote will remain open for 72 hours (or longer if needed). There were a number of changes made since RC1 to address concerns raised in previous votes. Among them: * License texts in lib/licenses where removed and incorporated into a monolithic top-level LICENSE.txt. CASSANDRA-371 * Attributions for all third-party code was added to the top-level NOTICE.txt file. CASSANDRA-371 * Commons javaflow was removed. CASSANDRA-428 * The developers/contributors reference in NOTICE.txt was removed, (as was the actual list in pom.xml). CASSANDRA-415 * Missing SVN properties that had crept in were added, and project documentation updated. CASSANDRA-429 +1 to release. Concerns/Issues/general feedback: - gen-java as mentioned like Sebb (The generated files included in the tarball), but not a blocking problem. We have various generated bits in httpd's tarbals, I don't think this is a critical issue. - The use of SVN Snapshots of projects like Thrift -- This is really a Thrift problem that the Thrift project needs to fix, but it should not block Cassandra from releasing. We have done releases of httpd that depend on APR svn snapshots before, it sucks, but we've done it. - Don't know the details of how `ant release` works, but things like bin/cassandra didn't have +x executable bit on them. - The BUGS.txt file feels out of place and pretty short, Maybe a Current Limitations section in a the README.txt, with a link to the wiki. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
