RE: [VOTE] Accept Aries proposal for incubation
+1 Cheers, Adam
RE: [VOTE] Accept Aries proposal for incubation
+1 --- Noel - 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
See https://issues.apache.org/jira/browse/INFRA-2242 I've already addressed those I could (i.e. confluence and svn) On Tue, Sep 22, 2009 at 22:03, Guillaume Nodet wrote: > On Tue, Sep 22, 2009 at 21:40, Kevan Miller wrote: >> >> On Sep 22, 2009, at 2:47 PM, Upayavira wrote: >> >>> On Tue, 2009-09-22 at 10:15 -0700, Martin Cooper wrote: I'd be interested in what people thought they voted for. The list of participants seems to have been constantly changing throughout the vote, but we can only be voting on one proposal, so which one was it? Did people who voted early implicitly vote for people who were not on the list at the time they voted? That doesn't sound right to me. >>> >>> They were voting on the proposal included in the initial vote mail. The >>> wiki is nothing more than a collaboration point for coming up with the >>> vote email. >>> >>> Any additions to the wiki since that vote are irrelevant, and must not >>> be included in the initial committer list. >> >> OK. So, I see two people (Adam Wojtuniak and Alan Keane) who asked to join >> the project yesterday and today. Agreed that they should be joining the >> project through normal community process, not via initial committer list. > > Agreed > >> >> I also see Niclas Hedhman's name on the Wiki list, but not on the initial >> committer's list. I'll also assume that Niclas should be joining the project >> via normal community processes. > > Given Niclas is a trusted ASF member, we may apply different rules here. > >> Finally, Bertrand Delacretaz volunteered to be a mentor, during the vote. I >> will assume his oversight is welcomed by all and will treat him as an >> initial mentor. > > +1 > > I will raise the INFRA issues to set up all the resources asap. > >> --kevan >> >> >> - >> 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 > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.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
On Tue, Sep 22, 2009 at 21:40, Kevan Miller wrote: > > On Sep 22, 2009, at 2:47 PM, Upayavira wrote: > >> On Tue, 2009-09-22 at 10:15 -0700, Martin Cooper wrote: >>> >>> >>> I'd be interested in what people thought they voted for. The list of >>> participants seems to have been constantly changing throughout the >>> vote, but we can only be voting on one proposal, so which one was it? >>> Did people who voted early implicitly vote for people who were not on >>> the list at the time they voted? That doesn't sound right to me. >> >> They were voting on the proposal included in the initial vote mail. The >> wiki is nothing more than a collaboration point for coming up with the >> vote email. >> >> Any additions to the wiki since that vote are irrelevant, and must not >> be included in the initial committer list. > > OK. So, I see two people (Adam Wojtuniak and Alan Keane) who asked to join > the project yesterday and today. Agreed that they should be joining the > project through normal community process, not via initial committer list. Agreed > > I also see Niclas Hedhman's name on the Wiki list, but not on the initial > committer's list. I'll also assume that Niclas should be joining the project > via normal community processes. Given Niclas is a trusted ASF member, we may apply different rules here. > Finally, Bertrand Delacretaz volunteered to be a mentor, during the vote. I > will assume his oversight is welcomed by all and will treat him as an > initial mentor. +1 I will raise the INFRA issues to set up all the resources asap. > --kevan > > > - > 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 - 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 22, 2009, at 2:47 PM, Upayavira wrote: On Tue, 2009-09-22 at 10:15 -0700, Martin Cooper wrote: I'd be interested in what people thought they voted for. The list of participants seems to have been constantly changing throughout the vote, but we can only be voting on one proposal, so which one was it? Did people who voted early implicitly vote for people who were not on the list at the time they voted? That doesn't sound right to me. They were voting on the proposal included in the initial vote mail. The wiki is nothing more than a collaboration point for coming up with the vote email. Any additions to the wiki since that vote are irrelevant, and must not be included in the initial committer list. OK. So, I see two people (Adam Wojtuniak and Alan Keane) who asked to join the project yesterday and today. Agreed that they should be joining the project through normal community process, not via initial committer list. I also see Niclas Hedhman's name on the Wiki list, but not on the initial committer's list. I'll also assume that Niclas should be joining the project via normal community processes. Finally, Bertrand Delacretaz volunteered to be a mentor, during the vote. I will assume his oversight is welcomed by all and will treat him as an initial mentor. --kevan - 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 Tue, 2009-09-22 at 10:15 -0700, Martin Cooper wrote: > On Tue, Sep 22, 2009 at 5:56 AM, Kevan Miller wrote: > > > > On Sep 22, 2009, at 12:09 AM, Niclas Hedhman wrote: > > > >> On Tue, Sep 22, 2009 at 2:36 AM, Jeremy Hughes wrote: > >> > If it IS a goal to become a large component registry for "anything > OSGI enterprisey" then my -1 vote will stand. > >>> > >>> Really it isn't. I mentioned earlier in this thread that Aries will > >>> seek to use components from other projects where they exist. > >> > >> I rest my case. Your argument is that the text is sufficient, I mean > >> it is not (too inclusive). > >> Let's adjourn this for the graduation. I am urging that the community > >> along the way think long and hard on the formulation of project > >> mission. > > > > Thanks Niclas. I certainly will be expecting (and prodding) the community to > > work at addressing your (and any other IPMC member's) concern. > > > > This vote has been open for a week, now. There's a lot of interest and > > support for the project. Concerns about the scope of the project have been > > raised. Addressing these concerns should be an important objective for the > > community. I think it's time to call this vote. Jeremy, since you initiated > > the VOTE, best for you to do the honors... > > I'd be interested in what people thought they voted for. The list of > participants seems to have been constantly changing throughout the > vote, but we can only be voting on one proposal, so which one was it? > Did people who voted early implicitly vote for people who were not on > the list at the time they voted? That doesn't sound right to me. They were voting on the proposal included in the initial vote mail. The wiki is nothing more than a collaboration point for coming up with the vote email. Any additions to the wiki since that vote are irrelevant, and must not be included in the initial committer list. Upayavira - 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 Tue, Sep 22, 2009 at 5:56 AM, Kevan Miller wrote: > > On Sep 22, 2009, at 12:09 AM, Niclas Hedhman wrote: > >> On Tue, Sep 22, 2009 at 2:36 AM, Jeremy Hughes wrote: >> If it IS a goal to become a large component registry for "anything OSGI enterprisey" then my -1 vote will stand. >>> >>> Really it isn't. I mentioned earlier in this thread that Aries will >>> seek to use components from other projects where they exist. >> >> I rest my case. Your argument is that the text is sufficient, I mean >> it is not (too inclusive). >> Let's adjourn this for the graduation. I am urging that the community >> along the way think long and hard on the formulation of project >> mission. > > Thanks Niclas. I certainly will be expecting (and prodding) the community to > work at addressing your (and any other IPMC member's) concern. > > This vote has been open for a week, now. There's a lot of interest and > support for the project. Concerns about the scope of the project have been > raised. Addressing these concerns should be an important objective for the > community. I think it's time to call this vote. Jeremy, since you initiated > the VOTE, best for you to do the honors... I'd be interested in what people thought they voted for. The list of participants seems to have been constantly changing throughout the vote, but we can only be voting on one proposal, so which one was it? Did people who voted early implicitly vote for people who were not on the list at the time they voted? That doesn't sound right to me. -- Martin Cooper > > --kevan > > > - > 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
[VOTE][RESULT] Aries proposal accepted for incubation (was: Re: [VOTE] Accept Aries proposal for incubation)
Hi, Results of the vote: 13 binding +1 votes, 2 binding -1 votes, 8 non-binding +1 votes. Davanum Srinivas(*)+1 Craig L Russell(*) +1 Ant Elder(*) +1 Daniel Kulp+1 Matthias Wessendorf+1 Kevan Miller(*)+1 James Strachan(*) +1 Guillaume Nodet(*) +1 Alan D. Cabrera(*) +1 Luciano Resende+1 Carsten Ziegeler(*)+1 Bill Stoddard(*) +1 Niklas Gustavsson +1 Jim Jagielski(*) -1 Niall Pemberton(*) +1 Donald Woods +1 Joe Bohn +1 Daniel S. Haischt +1 Niclas Hedhman(*) -1 Ralph Goers+1 Leo Simons(*) +1 Robert Burrell Donkin(*) +1 Bertrand Delecretaz(*) +1 Apache Aries proposal: http://wiki.apache.org/incubator/AriesProposal Reference to vote thread: http://mail-archives.apache.org/mod_mbox/incubator-general/200909.mbox/%3cadbf02b10909150854n5e5ed3c0je6f641a3d84fa...@mail.gmail.com%3e The mentors: Guillaume Nodet Davanum Srinivas (Dims) Kevan Miller Bertrand Delacretaz Thank you everyone for spending the time to review and comment. I'll work with the mentors to get the resources set up. Cheers, Jeremy - 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 22, 2009, at 12:09 AM, Niclas Hedhman wrote: On Tue, Sep 22, 2009 at 2:36 AM, Jeremy Hughes wrote: If it IS a goal to become a large component registry for "anything OSGI enterprisey" then my -1 vote will stand. Really it isn't. I mentioned earlier in this thread that Aries will seek to use components from other projects where they exist. I rest my case. Your argument is that the text is sufficient, I mean it is not (too inclusive). Let's adjourn this for the graduation. I am urging that the community along the way think long and hard on the formulation of project mission. Thanks Niclas. I certainly will be expecting (and prodding) the community to work at addressing your (and any other IPMC member's) concern. This vote has been open for a week, now. There's a lot of interest and support for the project. Concerns about the scope of the project have been raised. Addressing these concerns should be an important objective for the community. I think it's time to call this vote. Jeremy, since you initiated the VOTE, best for you to do the honors... --kevan - 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 21, 2009, at 9:09 PM, Niclas Hedhman wrote: On Tue, Sep 22, 2009 at 2:36 AM, Jeremy Hughes wrote: If it IS a goal to become a large component registry for "anything OSGI enterprisey" then my -1 vote will stand. Really it isn't. I mentioned earlier in this thread that Aries will seek to use components from other projects where they exist. I rest my case. Your argument is that the text is sufficient, I mean it is not (too inclusive). Let's adjourn this for the graduation. I am urging that the community along the way think long and hard on the formulation of project mission. My 2 cents. Let a thousand flowers bloom. IMO, mission statements are silly in that they are mere descriptions to attract contributors. An elevator speech if you will; though Aries' mission statement is irritatingly long winded as one of Bill Clinton's speeches. IMO, anyone trying to enforce a stricter usage of mission statements is protecting turf. I don't care if there is or isn't overlap w/ existing projects so long as there is a vibrant community behind it. Huge projects are not a problem until they try to protect their "turf". But turf protection is a potential problem of all projects; frankly some of the objections of other projects' members smacks of turf protection. Contributors are free to place their contributions where ever they wish. I trust the ASF membership to invariably provide an environment for free and unencumbered choices. Regards, Alan - 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 Tue, Sep 22, 2009 at 2:36 AM, Jeremy Hughes wrote: >> If it IS a goal to become a large component registry for "anything >> OSGI enterprisey" then my -1 vote will stand. > > Really it isn't. I mentioned earlier in this thread that Aries will > seek to use components from other projects where they exist. I rest my case. Your argument is that the text is sufficient, I mean it is not (too inclusive). Let's adjourn this for the graduation. I am urging that the community along the way think long and hard on the formulation of project mission. Someone already tallied the votes. Good Luck -- 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
Hi Niclas, 2009/9/19 Niclas Hedhman : > On Fri, Sep 18, 2009 at 8:10 PM, Guillaume Nodet wrote: >> The real goal as it has >> been said an OSGi Enterprise Programming Model, and the comparison >> that has been made with Geronimo is not bad. > > U... No. > > "The aim of the project is to produce a large and healthy community of > J2EE developers tasked with the development of an open source, > certified J2EE server..." > > IMHO, that is above and beyond what I am looking for. In fact, very > clear scope "certified J2EE server". > > > So instead of being critical, let me try and show with words what I > see the difference; > >> Just keep the following sentences in mind: "The Aries project will >> deliver a set of pluggable Java components enabling an enterprise OSGi >> application programming model. > > "The Aries project will define and develop an OSGi programming model, > that enables an inter-operable component eco-system for enterprise > OSGi applications (or servers)..." ?? > > And in order to do so, it is natural that reference components are > developed, but leave that out as a goal in itself. > If it is "conversion of the well-used J2EE specifications into > OSGi-enabled alternatives", i.e. "JNDI for OSGi", "JPA for OSGi" and > so on, then spell that out. You suggest the proposal spell out "conversion of the well-used J2EE specifications into OSGi-enabled alternatives" but I think it's actually more accurate to describe this in terms of implementing EEG specs (as the proposal does) - the EEG specs define how existing enterprise application technologies should be provided for in an OSGi environment and the current text accurately reflects the intention of the Aries project to provide implementation of these. Where Aries needs a capability it will look for the OSGi spec related to it. Where there isn't a spec we would develop the integration code anyway, building community along the way and subsequently work with the OSGi Alliance to consider what we found out by developing that implementation. > If it IS a goal to become a large component registry for "anything > OSGI enterprisey" then my -1 vote will stand. Really it isn't. I mentioned earlier in this thread that Aries will seek to use components from other projects where they exist: "It is the expectation that Aries will therefore not be delivering components such as ... Aries will instead seek to enable the use of such components from other projects." (from the proposal). The Aries focus is specifically on the enterprise application programming model when running in an OSGi environment, with the starting point being elaborated in "Initial Goals" and "Initial Source". Cheers, Jeremy - 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 Fri, Sep 18, 2009 at 8:10 PM, Guillaume Nodet wrote: > The real goal as it has > been said an OSGi Enterprise Programming Model, and the comparison > that has been made with Geronimo is not bad. U... No. "The aim of the project is to produce a large and healthy community of J2EE developers tasked with the development of an open source, certified J2EE server..." IMHO, that is above and beyond what I am looking for. In fact, very clear scope "certified J2EE server". So instead of being critical, let me try and show with words what I see the difference; > Just keep the following sentences in mind: "The Aries project will > deliver a set of pluggable Java components enabling an enterprise OSGi > application programming model. "The Aries project will define and develop an OSGi programming model, that enables an inter-operable component eco-system for enterprise OSGi applications (or servers)..." ?? And in order to do so, it is natural that reference components are developed, but leave that out as a goal in itself. If it is "conversion of the well-used J2EE specifications into OSGi-enabled alternatives", i.e. "JNDI for OSGi", "JPA for OSGi" and so on, then spell that out. If it IS a goal to become a large component registry for "anything OSGI enterprisey" then my -1 vote will stand. > 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." And the above part is Ok. > The first sentence is the key one. And that is the one that I don't like ;-) especially when looking at the filler text later. > It is what happened in other TLPs: Camel was first developed inside > ActiveMQ but moved to TLP because it did not really fit in ActiveMQ. > Felix Karaf has originally been developed inside ServiceMix for its > use, but given it was not really tied to ServiceMix, nor in the real > scope of the project, it has been moved as a Felix subproject. Well, IMHO, the wider the charter is written, the more unclear it becomes whether something belongs there or not. For instance, I think Felix is too encompassing and there is no 'natural' "move this out" threshold. Although that is a separate problem, I would like to avoid such scenarios in the future. 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
Hi, On Fri, Sep 18, 2009 at 8:39 PM, Davanum Srinivas wrote: > ...I am hoping that other incubator PMC members who have not VOTE'd would cast > their ballot as well... That's a hard one...let's say +1 But I expect the project to clarify its focus, and demonstrate collaboration with other Apache projects using OSGi during incubation. > ...It would be invaluable if any incubator PMC members > with concerns (or without!) could help us as mentors during the incubation > process Count me in - I'm in the "with concerns" group but optimistic (as usual ;-) Added my name to the list of mentors in the proposal. -Bertrand - 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
Folks, I see Niall, Leo, Jeremy, Robert, Bill and Guillaume respond to concerns from Jim and Niclas. It would be invaluable if any incubator PMC members with concerns (or without!) could help us as mentors during the incubation process. Here's the list of votes so far (see below). Noel, can you please chime in with your VOTE? I am hoping that other incubator PMC members who have not VOTE'd would cast their ballot as well thanks, dims Davanum Srinivas+1 Craig L Russell +1 Ant Elder +1 Daniel Kulp +1 Matthias Wessendorf +1 Kevan Miller+1 James Strachan +1 Guillaume Nodet +1 Alan D. Cabrera +1 Luciano Resende +1 Carsten Ziegeler+1 Bill Stoddard +1 Niklas Gustavsson +1 Jim Jagielski -1 Niall Pemberton +1 Donald Woods+1 Joe Bohn+1 Daniel S. Haischt +1 Niclas Hedhman -1 Ralph Goers +1 Leo Simons +1 Robert Burrell Donkin +1 On 09/18/2009 04:50 AM, Robert Burrell Donkin wrote: On Fri, Sep 18, 2009 at 8:05 AM, Niclas Hedhman wrote: On Fri, Sep 18, 2009 at 1:27 AM, Bill Stoddard wrote: I am having a really difficult time getting my head around Jim and Niclas' objections that this is an umbrella project. I think Jim came up with a good lithmus test; "If it is unclear what should NOT go into a project..." So, when I read the proposal the second time, my interpretation is that there is no actual boundary, other than perhaps "OSGi". If it was "only specs", then I would support Richard's notion that the community should work towards Felix sub-project (which was a sore point), but the scope is "enterprise OSGi", which is just about as wide as it gets. Perhaps the group as such has much better ideas on what they mean, fair enough, but then *I* would like to see it in the proposal. After all, it is very common around here that the proposal will become the basis for the project charter (if any), so *I* think it is better to address this early (and often ;-) )... it is not conventional here to insist on a set exit strategy before a proposal is approved. perhaps this innovation is one that should be considered but IMHO it's not really workable to do that this late in the acceptance process. targeting an exit as a felix sub-project would require the aries proposes to start again with approval from the felix proposal and so on. it may also prove controversial. i would also be worried about settling on exit as a felix sub-project now. i'm a big felix fan and think it runs very well. but i think there's a limit on how far it can scale without loosing it's cohesiveness as a community. i would like see felix continue to act as a home for cross cut OSGi components factored out of existing apache codebases. if there are going to be a large number of new OSGi specs with a distinctive "enterprise" identity (whatever that means) then i worry that the felix project may find themselves flooded and lose direction. i also worry that if no distinctive identity develops for "enterprise" specifications then aries is going to have scope issues. i'm not sure that this can be resolved right now: the specification process doesn't seem mature enough yet. but i don't see this as a reason to tell aries to come back later. code and community first. i would expect that the project reports include detail on the specifications they intend to implement and what progress has been made towards a tight definition of "enterprise" (whether as a distinctive group of specifications or a good description) - robert - 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
Re: [VOTE] Accept Aries proposal for incubation
I guess this is really a wording problem. I don't think anyone is thinking about bringing Geronimo, James, ServiceMix, CXF, Axis, ActiveMQ or anything like that into Aries. The real goal as it has been said an OSGi Enterprise Programming Model, and the comparison that has been made with Geronimo is not bad. We already know it will include some of the specs that comes from the OSGi Enterprise Expert Group and that's why they have been mentioned. Just keep the following sentences in mind: "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." The first sentence is the key one. The second one just try to explicit it by listing things that we know or think will be developed in Aries. Or at least, that Aries would need to define its programming model.Please read the relationship between Aries and various other TLPs. For example the OpenJPA section. Aries doesn't aim at implementing JPA, but it aims at integrating JPA into OSGi. I think the same would be true for JMS / ActiveMQ. I think for each technology Aries enables, we'll have first to develop this integration layer, then if it makes more sense to contribute it back to another TLP, it will be done. I think that's how it should work. It is what happened in other TLPs: Camel was first developed inside ActiveMQ but moved to TLP because it did not really fit in ActiveMQ. Felix Karaf has originally been developed inside ServiceMix for its use, but given it was not really tied to ServiceMix, nor in the real scope of the project, it has been moved as a Felix subproject. Just let us create the community and I'm sure it will find a good way to nicely cooperate with other TLPs. On Fri, Sep 18, 2009 at 13:26, Niclas Hedhman wrote: > On Fri, Sep 18, 2009 at 4:50 PM, Robert Burrell Donkin > wrote: > >> targeting an exit as a felix sub-project would require the aries >> proposes to start again with approval from the felix proposal and so >> on. it may also prove controversial. > > You missed the point. It is not about exit strategy, it is about "What > belongs and/or not in Aries?". That question is answered in the > proposal like "enterprise spec impl", but also "anything OSGi > enterprisey", which I then claim includes he components for just about > every single project (impl using OSGi) at the ASF. ServiceMix is using > OSGi, so of course anything that can be componentized should be stuck > into Aries. How about James? Are you guys in OSGi yet? So, your > components go into Aries, right? How about Geronimo? WS-*? > If the proposal is re-written to a more concise language of what the > focus really is, then I gladly change my vote. > > > 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 > > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.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
On Fri, Sep 18, 2009 at 4:50 PM, Robert Burrell Donkin wrote: > targeting an exit as a felix sub-project would require the aries > proposes to start again with approval from the felix proposal and so > on. it may also prove controversial. You missed the point. It is not about exit strategy, it is about "What belongs and/or not in Aries?". That question is answered in the proposal like "enterprise spec impl", but also "anything OSGi enterprisey", which I then claim includes he components for just about every single project (impl using OSGi) at the ASF. ServiceMix is using OSGi, so of course anything that can be componentized should be stuck into Aries. How about James? Are you guys in OSGi yet? So, your components go into Aries, right? How about Geronimo? WS-*? If the proposal is re-written to a more concise language of what the focus really is, then I gladly change my vote. 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 Fri, Sep 18, 2009 at 8:05 AM, Niclas Hedhman wrote: > On Fri, Sep 18, 2009 at 1:27 AM, Bill Stoddard wrote: > >> I am having a really difficult time getting my head around Jim and Niclas' >> objections that this is an umbrella project. > > I think Jim came up with a good lithmus test; "If it is unclear what > should NOT go into a project..." > > So, when I read the proposal the second time, my interpretation is > that there is no actual boundary, other than perhaps "OSGi". If it was > "only specs", then I would support Richard's notion that the community > should work towards Felix sub-project (which was a sore point), but > the scope is "enterprise OSGi", which is just about as wide as it > gets. Perhaps the group as such has much better ideas on what they > mean, fair enough, but then *I* would like to see it in the proposal. > After all, it is very common around here that the proposal will become > the basis for the project charter (if any), so *I* think it is better > to address this early (and often ;-) )... it is not conventional here to insist on a set exit strategy before a proposal is approved. perhaps this innovation is one that should be considered but IMHO it's not really workable to do that this late in the acceptance process. targeting an exit as a felix sub-project would require the aries proposes to start again with approval from the felix proposal and so on. it may also prove controversial. i would also be worried about settling on exit as a felix sub-project now. i'm a big felix fan and think it runs very well. but i think there's a limit on how far it can scale without loosing it's cohesiveness as a community. i would like see felix continue to act as a home for cross cut OSGi components factored out of existing apache codebases. if there are going to be a large number of new OSGi specs with a distinctive "enterprise" identity (whatever that means) then i worry that the felix project may find themselves flooded and lose direction. i also worry that if no distinctive identity develops for "enterprise" specifications then aries is going to have scope issues. i'm not sure that this can be resolved right now: the specification process doesn't seem mature enough yet. but i don't see this as a reason to tell aries to come back later. code and community first. i would expect that the project reports include detail on the specifications they intend to implement and what progress has been made towards a tight definition of "enterprise" (whether as a distinctive group of specifications or a good description) - robert - 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 Fri, Sep 18, 2009 at 1:27 AM, Bill Stoddard wrote: > I am having a really difficult time getting my head around Jim and Niclas' > objections that this is an umbrella project. I think Jim came up with a good lithmus test; "If it is unclear what should NOT go into a project..." So, when I read the proposal the second time, my interpretation is that there is no actual boundary, other than perhaps "OSGi". If it was "only specs", then I would support Richard's notion that the community should work towards Felix sub-project (which was a sore point), but the scope is "enterprise OSGi", which is just about as wide as it gets. Perhaps the group as such has much better ideas on what they mean, fair enough, but then *I* would like to see it in the proposal. After all, it is very common around here that the proposal will become the basis for the project charter (if any), so *I* think it is better to address this early (and often ;-) )... 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
Jeremy Hughes wrote: 2009/9/16 Jim Jagielski : On Sep 16, 2009, at 4:32 AM, Niall Pemberton wrote: ... IMO this is more a graduation issue, rather than something that should prevent entry to the incubator - since thats when destination is decided. There are many possible outcomes from that - perhaps some parts will go to felix and others to a new TLP(s) - but I say lets see how it works out during graduation rather than shooting it down now. I agree that the rubber hits the road when graduation, and when there is a resolution before the board to make this a TLP. However, my thoughts are that without this concern front-and-center from the get-go, the podling runs the risk of hitting this roadblock right at the end, at which point who knows how much impact this may have on it... In other words, if a podling umbrella attempts to graduate into a TLP umbrella, it will likely be shot down. Do we really want to wait until the end to address this once and for all? Just my 2c. PS: BTW, I think it's a great proposal and podling and technically am a big +1 on it. My only concern is lack of directed focus... It is not our intent to create an umbrella TLP - the focus of Aries is specifically on developing the componentry needed to enable an enterprise OSGi application prgramming model. This will include implementing some of the OSGi EEG specs - the initial focus is as described in the sections "Initial Goals" and "Initial Source" but the proposal also tries to make it clear that Aries will consume technology from other projects where available: "It is the expectation that Aries will therefore not be delivering components such as ... Aries will instead seek to enable the use of such components from other projects." We are starting out largely speaking as a community of people with a heritage in enterprise Java runtimes looking to encouarge the exploitation of OSGi by the applications deployed to enterprise environments. We are not looking to target specific runtimes or to implement *every* spec that comes out of the EEG but we are looking to build coherent componentry needed by enterprise applications when deployed as OSGi bundles to an enterprise runtime. We've described this in the "Relationship with Other Apache Projects" section. How we evolve from the stated "initial goals" will largely depend on the community that forms - which I believe is reasonable for a new incubator. To help remove any impression that Aries is looking to become an umbrella TLP we could perhaps reword the first sentence of the proposal from "It is a goal of the Aries project to provide a natural home for open source implementations of current and future OSGi EEG specifications, .." to "It is a goal of the Aries project to implement OSGi EEG specifications that are part of the enterprise application programming model, " to clarify the scope - this remains consistent with the rest of the proposal. Thanks, Jeremy Crickets it's terribly quiet around here.. I am having a really difficult time getting my head around Jim and Niclas' objections that this is an umbrella project. The mother of all umbrella projects was Jakarta... (coded in Java? It should go into Jakarta...); this proposal clearly isn't that. This proposal is concerned with implementing an OSGi application programming model; it relies heavily on specs from the OSGi Alliance Enterprise Expert Group (EEG) and the EEG itself is a small, narrowly scoped part of the OSGi Alliance. The project scope seems pretty darn succinct to me. What am I missing? What I see here is a surprisingly diverse group of developers interested in working on a project and having the freedom to bring the vision to fruition. A lot like Geronimo really, whose mission is to implement the JEE programming model. Geronimo draws heavily on projects from both inside and outside the ASF. If the Geronimo team requires a piece of technology that's not available, they collaborate with other groups to obtain it or do the work themselves at last resort. In other words, Geronimo has operational freedom to control its own destiny. Not a bad thing, imho. It's pretty clear (at least to me :-) that the Aries proposal is more tightly scoped than even Geronimo and Geronimo works reasonably well. The project proposers clearly know -where- they want to go (and have communicated that in the proposal) .. what's understandably less clear is precisely how they are going to get there... that's why a degree of operational freedom is important; attempting to nail the proposers down to a precise path right now is counter productive to the success of the project. Bill - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Accept Aries proposal for incubation
On Wed, Sep 16, 2009 at 7:25 PM, Leo Simons wrote: > On Wed, Sep 16, 2009 at 1:09 PM, Jim Jagielski wrote: >> On Sep 16, 2009, at 4:32 AM, Niall Pemberton wrote: >>> On Tue, Sep 15, 2009 at 11:43 PM, Niclas Hedhman wrote: On Tue, Sep 15, 2009 at 9:07 PM, Jim Jagielski 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. >>> >>> IMO this is more a graduation issue, rather than something that should >>> prevent entry to the incubator - since thats when destination is >>> decided. There are many possible outcomes from that - perhaps some >>> parts will go to felix and others to a new TLP(s) - but I say lets see >>> how it works out during graduation rather than shooting it down now. >> >> I agree that the rubber hits the road when graduation, and when there >> is a resolution before the board to make this a TLP. However, my >> thoughts are that without this concern front-and-center from the get-go, >> the podling runs the risk of hitting this roadblock right at the end, >> at which point who knows how much impact this may have on it... In other >> words, if a podling umbrella attempts to graduate into a TLP umbrella, it >> will likely be shot down. Do we really want to wait until the end to >> address this once and for all? > > I understand and subscribe to the concern. +1 this is an entry proposal, not one for graduation > However, > > 1) it sounds like most of the Aries folk are aware of the need to > balance this kind of thing out a bit > 2) not all umbrellas are all bad (some projects with pretty broad > scopes and many subprojects AND healthy communities AND good oversight > include geronimo, maven, felix, hadoop, commons, and others) +1 the umbrella concerns were about community and oversight, and not software architecture the key question is not whether apache should host modular components (we do this already) but whether aries has a tight enough focus to work as a community > 3) I think the main issue is the sweeping statements in the proposal > which is typical of java framework land, but in practice I suspect the > actual project focus is pretty narrow, people just don't really know > how to express that yet > 4) given #3, I suspect that as the project matures its scope > definition is easier so that we'll see a nice and specific board > resolution eventually +1 but this is going to be one of the major graduation issues and shouldn't be left to the end > So I'm personally rather optimistic that things will work out ok, and > so here's my +1 to the proposal. i'm +1 on the proposal - robert - 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
2009/9/16 Jim Jagielski : > > On Sep 16, 2009, at 4:32 AM, Niall Pemberton wrote: ... >> IMO this is more a graduation issue, rather than something that should >> prevent entry to the incubator - since thats when destination is >> decided. There are many possible outcomes from that - perhaps some >> parts will go to felix and others to a new TLP(s) - but I say lets see >> how it works out during graduation rather than shooting it down now. >> > > I agree that the rubber hits the road when graduation, and when there > is a resolution before the board to make this a TLP. However, my > thoughts are that without this concern front-and-center from the get-go, > the podling runs the risk of hitting this roadblock right at the end, > at which point who knows how much impact this may have on it... In other > words, if a podling umbrella attempts to graduate into a TLP umbrella, it > will likely be shot down. Do we really want to wait until the end to > address this once and for all? > > Just my 2c. > > PS: BTW, I think it's a great proposal and podling and technically am a big > +1 on it. My only concern is lack of directed focus... It is not our intent to create an umbrella TLP - the focus of Aries is specifically on developing the componentry needed to enable an enterprise OSGi application prgramming model. This will include implementing some of the OSGi EEG specs - the initial focus is as described in the sections "Initial Goals" and "Initial Source" but the proposal also tries to make it clear that Aries will consume technology from other projects where available: "It is the expectation that Aries will therefore not be delivering components such as ... Aries will instead seek to enable the use of such components from other projects." We are starting out largely speaking as a community of people with a heritage in enterprise Java runtimes looking to encouarge the exploitation of OSGi by the applications deployed to enterprise environments. We are not looking to target specific runtimes or to implement *every* spec that comes out of the EEG but we are looking to build coherent componentry needed by enterprise applications when deployed as OSGi bundles to an enterprise runtime. We've described this in the "Relationship with Other Apache Projects" section. How we evolve from the stated "initial goals" will largely depend on the community that forms - which I believe is reasonable for a new incubator. To help remove any impression that Aries is looking to become an umbrella TLP we could perhaps reword the first sentence of the proposal from "It is a goal of the Aries project to provide a natural home for open source implementations of current and future OSGi EEG specifications, .." to "It is a goal of the Aries project to implement OSGi EEG specifications that are part of the enterprise application programming model, " to clarify the scope - this remains consistent with the rest of the proposal. Thanks, Jeremy - 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 Wed, Sep 16, 2009 at 1:09 PM, Jim Jagielski wrote: > On Sep 16, 2009, at 4:32 AM, Niall Pemberton wrote: >> On Tue, Sep 15, 2009 at 11:43 PM, Niclas Hedhman wrote: >>> On Tue, Sep 15, 2009 at 9:07 PM, Jim Jagielski 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. >> >> IMO this is more a graduation issue, rather than something that should >> prevent entry to the incubator - since thats when destination is >> decided. There are many possible outcomes from that - perhaps some >> parts will go to felix and others to a new TLP(s) - but I say lets see >> how it works out during graduation rather than shooting it down now. > > I agree that the rubber hits the road when graduation, and when there > is a resolution before the board to make this a TLP. However, my > thoughts are that without this concern front-and-center from the get-go, > the podling runs the risk of hitting this roadblock right at the end, > at which point who knows how much impact this may have on it... In other > words, if a podling umbrella attempts to graduate into a TLP umbrella, it > will likely be shot down. Do we really want to wait until the end to > address this once and for all? I understand and subscribe to the concern. However, 1) it sounds like most of the Aries folk are aware of the need to balance this kind of thing out a bit 2) not all umbrellas are all bad (some projects with pretty broad scopes and many subprojects AND healthy communities AND good oversight include geronimo, maven, felix, hadoop, commons, and others) 3) I think the main issue is the sweeping statements in the proposal which is typical of java framework land, but in practice I suspect the actual project focus is pretty narrow, people just don't really know how to express that yet 4) given #3, I suspect that as the project matures its scope definition is easier so that we'll see a nice and specific board resolution eventually So I'm personally rather optimistic that things will work out ok, and so here's my +1 to the proposal. cheers, - Leo > PS: BTW, I think it's a great proposal and podling and technically am a big > +1 on it. My only concern is lack of directed focus... - 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 16, 2009, at 4:32 AM, Niall Pemberton wrote: On Tue, Sep 15, 2009 at 11:43 PM, Niclas Hedhman wrote: On Tue, Sep 15, 2009 at 9:07 PM, Jim Jagielski 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. IMO this is more a graduation issue, rather than something that should prevent entry to the incubator - since thats when destination is decided. There are many possible outcomes from that - perhaps some parts will go to felix and others to a new TLP(s) - but I say lets see how it works out during graduation rather than shooting it down now. I agree that the rubber hits the road when graduation, and when there is a resolution before the board to make this a TLP. However, my thoughts are that without this concern front-and-center from the get-go, the podling runs the risk of hitting this roadblock right at the end, at which point who knows how much impact this may have on it... In other words, if a podling umbrella attempts to graduate into a TLP umbrella, it will likely be shot down. Do we really want to wait until the end to address this once and for all? Just my 2c. PS: BTW, I think it's a great proposal and podling and technically am a big +1 on it. My only concern is lack of directed focus... - 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 Tue, Sep 15, 2009 at 11:43 PM, Niclas Hedhman wrote: > On Tue, Sep 15, 2009 at 9:07 PM, Jim Jagielski 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. IMO this is more a graduation issue, rather than something that should prevent entry to the incubator - since thats when destination is decided. There are many possible outcomes from that - perhaps some parts will go to felix and others to a new TLP(s) - but I say lets see how it works out during graduation rather than shooting it down now. Niall Niall > Cheers > -- > Niclas Hedhman, Software Developer - 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] Accept Aries proposal for incubation
On Tue, Sep 15, 2009 at 9:07 PM, Jim Jagielski 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
[x] +1 Accept Aries for incubation Cheers Daniel On Tue, Sep 15, 2009 at 5:54 PM, 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 severa
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 te
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 tec
Re: [VOTE] Accept Aries proposal for incubation
+1 Niall On Tue, Sep 15, 2009 at 4:54 PM, 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 Enterp
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
Re: [VOTE] Accept Aries proposal for incubation
On Tue, Sep 15, 2009 at 5:54 PM, Jeremy Hughes 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
+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 technologies
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 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 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 On Tuesday, September 15, 2009, 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 Enterp
Re: [VOTE] Accept Aries proposal for incubation
+1 2009/9/15 Jeremy Hughes : > 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 Allianc
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 a
Re: [VOTE] Accept Aries proposal for incubation
+1 On Tue, Sep 15, 2009 at 6:24 PM, Daniel Kulp 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 enterp
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
Re: [VOTE] Accept Aries proposal for incubation
+1 ...ant On Tue, Sep 15, 2009 at 4:54 PM, 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 En
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 app
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
