Re: [VOTE] Apache Tamaya for Incubation
+1 regards, gerhard 2014-11-13 9:16 GMT+01:00 Mark Struberg strub...@yahoo.de: +1 (binding) LieGrue, strub On Tuesday, 11 November 2014, 12:20, John D. Ament john.d.am...@gmail.com wrote: Anatole, Actually the name suitability is a long, drawn out process. i started it here just now for the project: https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-60 You can read the details here: http://incubator.apache.org/guides/names.html - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] BatchEE as an incubated project
+1 regards, gerhard 2013/9/30 Matthias Wessendorf mat...@apache.org +1 (binding) On Monday, September 30, 2013, Mark Struberg wrote: +1 (binding) LieGrue, strub - Original Message - From: Romain Manni-Bucau rmannibu...@gmail.com To: general@incubator.apache.org Cc: Sent: Monday, 30 September 2013, 6:52 Subject: [VOTE] BatchEE as an incubated project Since discussion about the BatchEE seems done, I'd like to call a vote for BatchEE to become an incubated project. The proposal is pasted below, and also available at: https://wiki.apache.org/incubator/BatchEEProposal Let's keep this vote open for three business days, closing the voting on Thursday 10/03. [ ] +1 Accept BatchEE into the Incubator [ ] +0 Don't care. [ ] -1 Don't accept BatchEE because... = BatchEE, JBatch Implementation = === Abstract === BatchEE will be an ASL-licensed implementation of the JBatch Specification which is defined as JSR-352 (for version 1.0). === Proposal === BatchEE specification is an effort for defining a standard API and way to write batches in Java. It is integrated with JavaEE (JTA, CDI) but works out of the box in a standalone environment. BatchEE Project is responsible for implementing the runtime container contract for the JBatch specification. Besides the implementation, BatchEE Project will implement the core built-in components that further simplifies the developer complex interactions with other Java EE specific enterprise operations. For example, it will define default reader/processor/writer for jdbc, jpa, xml/json/flat files... === Background === Until today writing batches in java meant using a proprietary framework and link to JavaEE was quite limited (or missing). JBatch defines an API fixing this issue and now developpers need a fix. === Rationale === Current JBatch specificatin is released, and only the reference implementation is available but not really intended to be maintained. Moreover multiple Apache projects (geronimo, TomEE, ...) will need an Apache compatible Jbatch implementation to go ahread and implement JavaEE 7. === Initial Goals === The initial goals of the BatchEE Project are * Fully implement the JSR-352 specification. * Attracts a community around the current code base. * Active relationship with the other dependent projects to further develop some useful batch components. == Current Status == === Meritocracy === Initial developer of the project is familiar with the meritocracy principles of Apache. He knows that the open source gets power from its great developers and freedom. He also developed some other open source projects. We will follow the normal meritocracy rules also with other potential contributors. === Community === There is a great community within the OpenEJB, OpenWebBeans, Geronimo and TomEE Apache projects. BatchEE project is very related with these projects and in the some cases, it enhances these projects. We are thinking that BatchEE project gets strong community because it complete the needed frameworks of a java developper and unifies the using of these projects. It simplifies the developer effort for building complex enterprise applications batches. === Core Developers === BatchEE project has been developing by the IBM then forked by Romain Manni-Bucau as a sole contributor. === Alignment === BacthEE project will be a candidate for use in Geronimo AS and TomEE as a default JBatch implementation. Other projects could benefit from the BatchEE project as a general purpose component and context management. BatchEE project is closely aligned with the OpenEJB and OpenWebBeans projects perfectly. It depends on these projects to satisfy its requirements (mainly tests). == Known Risks == === Orphaned products === Even if the initial committer of the project has no plan to leave the active development, it must necessa- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org javascript:; For additional commands, e-mail: general-h...@incubator.apache.org javascript:; -- Sent from Gmail Mobile
Re: [PROPOSAL] BatchEE to implement JBatch @apache
easybatch is used by others already. regards, gerhard 2013/9/19 Romain Manni-Bucau rmannibu...@gmail.com Ok guys, if I have 2 others +1 I update the proposal ;) (I think you are right, that's why i proposed it) *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/9/19 Jean-Baptiste Onofré j...@nanthrax.net +1, to be honest, I prefer EasyBatch as BatchEE sounds like related to JavaEE which can be confusing for the users. Regards JB On 09/19/2013 01:31 PM, Romain Manni-Bucau wrote: Discussing with a colleague he proposed me another name: EasyBatch. Personally I like BatchEE but EasyBatch sounds quite fun even if maybe too close to RestEasy ;) wdyt? Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.**com/ http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/**rmannibucau http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2013/9/18 Romain Manni-Bucau rmannibu...@gmail.com: Added you , thks Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.**com/ http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/**rmannibucau http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2013/9/18 Olivier Lamy ol...@apache.org: Sounds interesting. Add me as mentor if needed. Cheers -- Olivier On Sep 17, 2013 8:22 PM, Romain Manni-Bucau rmannibu...@gmail.com wrote: Dear ASF members, I would like to propose the BatchEE project to the Incubator. The BatchEE proposal is available at: https://wiki.apache.org/**incubator/BatchEEProposal https://wiki.apache.org/incubator/BatchEEProposal I welcome your feedbacks and suggestions. Thanks! Here is a copy of the proposal: = BatchEE, JBatch Implementation = === Abstract === BatchEE will be an ASL-licensed implementation of the JBatch Specification which is defined as JSR-352 (for version 1.0). === Proposal === BatchEE specification is an effort for defining a standard API and way to write batches in Java. It is integrated with JavaEE (JTA, CDI) but works out of the box in a standalone environment. BatchEE Project is responsible for implementing the runtime container contract for the JBatch specification. Besides the implementation, BatchEE Project will implement the core built-in components that further simplifies the developer complex interactions with other Java EE specific enterprise operations. For example, it will define default reader/processor/writer for jdbc, jpa, xml/json/flat files... === Background === Until today writing batches in java meant using a proprietary framework and link to JavaEE was quite limited (or missing). JBatch defines an API fixing this issue and now developpers need a fix. === Rationale === Current JBatch specificatin is released, and only the reference implementation is available but not really intended to be maintained. Moreover multiple Apache projects (geronimo, TomEE, ...) will need an Apache compatible Jbatch implementation to go ahread and implement JavaEE 7. === Initial Goals === The initial goals of the BatchEE Project are * Fully implement the JSR-352 specification. * Attracts a community around the current code base. * Active relationship with the other dependent projects to further develop some useful batch components. == Current Status == === Meritocracy === Initial developer of the project is familiar with the meritocracy principles of Apache. He knows that the open source gets power from its great developers and freedom. He also developed some other open source projects. We will follow the normal meritocracy rules also with other potential contributors. === Community === There is a great community within the OpenEJB, OpenWebBeans, Geronimo and TomEE Apache projects. BatchEE project is very related with these projects and in the some cases, it enhances these projects. We are thinking that BatchEE project gets strong community because it complete the needed frameworks of a java developper and unifies the using of these projects. It simplifies the developer effort for building complex enterprise applications batches. === Core Developers === BatchEE project has been developing by the IBM then forked by Romain Manni-Bucau as a sole contributor. === Alignment === BacthEE project will be a candidate for use in Geronimo AS and TomEE as a default JBatch implementation. Other projects could benefit from the BatchEE project as a general purpose component and context management. BatchEE project is closely aligned with the OpenEJB
Re: [PROPOSAL] BatchEE to implement JBatch @apache
hi john, please have a look at [1]. regards, gerhard [1] http://s.apache.org/Ns7 2013/9/19 John D. Ament john.d.am...@gmail.com Just wondering, even though the RI is ASL2, do we need to get IP clearance to fork? I think this last came up with BeanShell. John On Thu, Sep 19, 2013 at 11:20 AM, Matt Benson gudnabr...@gmail.com wrote: JSR 352 is part of Java EE 7, so BatchEE is IMO warranted. Plus the rhyming of Apache BatchEE is silly and fun. $0.02, Matt On Thu, Sep 19, 2013 at 10:08 AM, Gerhard Petracek gerhard.petra...@gmail.com wrote: easybatch is used by others already. regards, gerhard 2013/9/19 Romain Manni-Bucau rmannibu...@gmail.com Ok guys, if I have 2 others +1 I update the proposal ;) (I think you are right, that's why i proposed it) *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/9/19 Jean-Baptiste Onofré j...@nanthrax.net +1, to be honest, I prefer EasyBatch as BatchEE sounds like related to JavaEE which can be confusing for the users. Regards JB On 09/19/2013 01:31 PM, Romain Manni-Bucau wrote: Discussing with a colleague he proposed me another name: EasyBatch. Personally I like BatchEE but EasyBatch sounds quite fun even if maybe too close to RestEasy ;) wdyt? Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.**com/ http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/**rmannibucau http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2013/9/18 Romain Manni-Bucau rmannibu...@gmail.com: Added you , thks Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.**com/ http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/**rmannibucau http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2013/9/18 Olivier Lamy ol...@apache.org: Sounds interesting. Add me as mentor if needed. Cheers -- Olivier On Sep 17, 2013 8:22 PM, Romain Manni-Bucau rmannibu...@gmail.com wrote: Dear ASF members, I would like to propose the BatchEE project to the Incubator. The BatchEE proposal is available at: https://wiki.apache.org/**incubator/BatchEEProposal https://wiki.apache.org/incubator/BatchEEProposal I welcome your feedbacks and suggestions. Thanks! Here is a copy of the proposal: = BatchEE, JBatch Implementation = === Abstract === BatchEE will be an ASL-licensed implementation of the JBatch Specification which is defined as JSR-352 (for version 1.0). === Proposal === BatchEE specification is an effort for defining a standard API and way to write batches in Java. It is integrated with JavaEE (JTA, CDI) but works out of the box in a standalone environment. BatchEE Project is responsible for implementing the runtime container contract for the JBatch specification. Besides the implementation, BatchEE Project will implement the core built-in components that further simplifies the developer complex interactions with other Java EE specific enterprise operations. For example, it will define default reader/processor/writer for jdbc, jpa, xml/json/flat files... === Background === Until today writing batches in java meant using a proprietary framework and link to JavaEE was quite limited (or missing). JBatch defines an API fixing this issue and now developpers need a fix. === Rationale === Current JBatch specificatin is released, and only the reference implementation is available but not really intended to be maintained. Moreover multiple Apache projects (geronimo, TomEE, ...) will need an Apache compatible Jbatch implementation to go ahread and implement JavaEE 7. === Initial Goals === The initial goals of the BatchEE Project are * Fully implement the JSR-352 specification. * Attracts a community around the current code base. * Active relationship with the other dependent projects to further develop some useful batch components. == Current Status == === Meritocracy === Initial developer of the project is familiar with the meritocracy principles of Apache. He knows that the open source gets power from its great developers and freedom. He also developed some other open source projects. We will follow the normal meritocracy rules also with other potential contributors. === Community
Re: [DISCUSS] jbatch impl @Apache?
+1 regards, gerhard 2013/9/16 Romain Manni-Bucau rmannibu...@gmail.com Hi, Now Scott informed us we can fork the RI ( http://apache-incubator-general.996316.n3.nabble.com/Re-DISCUSS-jbatch-impl-Apache-td36529.html ) is it ok to start to write a proposal? Le 30 août 2013 15:23, Romain Manni-Bucau rmannibu...@gmail.com a écrit : Hi added some few modules: * shiro: nothing fancy just a simple SecurityService which check some perm to start/restart jobs - mainly to show how to write a custom one * extras: some readers/writers (flat, StAX) * beanio: integration with BeanIO framework I'll be quite off next week but any feedback + help to go ahead would be perfect *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/8/27 Romain Manni-Bucau rmannibu...@gmail.com Hi here is the fork: https://github.com/rmannibucau/batchee I created a parent module even if not yet mandatory since we will surely add a kind of extra module with readers, writers etc... I put a TODO.md with tasks i see as important to do mvn clean install will execute TCKs (normally it should be green in java 6 or 7) *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/8/27 Andy Van Den Heuvel andy.vandenheu...@gmail.com Great, Keep us posted. On Tue, Aug 27, 2013 at 10:36 AM, Romain Manni-Bucau rmannibu...@gmail.comwrote: Great to here, i plan to create a fork (maybe copy is more appropriated here) on my github for the end of this week (hopefully) then we can maybe discuss around it, does it work for you? *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/8/27 Mark Struberg strub...@yahoo.de I'd definitly need a jBatch here for some customers and I'd be happy to help with hacking, testing and even mentoring. LieGrue, strub - Original Message - From: Alan Cabrera l...@toolazydogs.com To: general@incubator.apache.org Cc: Sent: Monday, 26 August 2013, 17:15 Subject: Re: [DISCUSS] jbatch impl @Apache? Is there enough interest to generate an active community for this? Would it make more sense to do this work under Geronimo or TomEE? Regards, Alan On Aug 26, 2013, at 7:01 AM, Romain Manni-Bucau rmannibu...@gmail.com wrote: Hi As you probably know JavaEE 7 proposes a new spec called JBatch (aka JSR 352). I'd love to see an implementation @Apache. There is ATM only one implementation (spring-batch doesn't pass the full TCKs): the RI (done by IBM). AFAIK they doesn't aim to create a community about this spec but their implementation is under the license Apache v2 and starting to implement it from scratch i started to get something very close to them (i just started but seeing my classes so close i decided to stop my impl from scratch and see if forking wouldn't be a better/easier solution). Personally my plan would be to fork their code and clean/update it and create a community around it. About it i have some questions: 1) does it sound good? 2) any interested people? 3) how to process exactly? *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* - 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] recommend Apache DeltaSpike for graduating out of the incubator
+1
regards,
gerhard
2013/3/30 Mark Struberg strub...@yahoo.de
Hi!
The Apache DeltaSpike podling is a project which contains common CDI
Extensions which are portable among many different Java EE containers and
even run on standalone CDI containers.
We are now incubating since December 2011 and believe we are ready for
graduation. We've shipped 3 releases and already see wide adoption in the
industry.
We've already done an internal VOTE on the proposal which passed with a
big majority [1].
The voices who raised concerns were mainly afraid of DeltaSpike not being
'finished' yet. But graduation doesn't mean that the product is final and
switches to maintenance, but that it is vital and there is an active
community around it. And this is certainly the case as shown by the 21
votes we got the last days.
Our status file [2] got updated recently and I consider the podling
namesearch task as completed [3].
Thus I'd like to ask the IPMC to VOTE on recommending the attached
graduation proposal to the board.
[+1] yes, go forward
[+0] meh, don't care
[-1] nope, because there's a blocker ${blocker_reason}
The VOTE is open for 72h
txs and LieGrue,
strub
[1] http://markmail.org/message/bmhr5woxidmgheco
[2] http://incubator.apache.org/projects/deltaspike.html
[3] https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-31
Proposed Board Resolution Report
X. Establish the Apache DeltaSpike Project
WHEREAS, the Board of Directors deems it to be in the best
interests of the Foundation and consistent with the
Foundation's purpose to establish a Project Management
Committee charged with the creation and maintenance of
open-source software related to creating a set
of portable CDI (JSR-299) Extensions
for distribution at no charge to the public.
NOW, THEREFORE, BE IT RESOLVED, that a Project Management
Committee (PMC), to be known as the Apache DeltaSpike Project,
be and hereby is established pursuant to Bylaws of the
Foundation; and be it further
RESOLVED, that the Apache DeltaSpike Project be and hereby is
responsible for the creation and maintenance of open-source
software related to creating a set of portable CDI Extensions;
and be it further
RESOLVED, that the office of Vice President, Apache DeltaSpike be
and hereby is created, the person holding such office to
serve at the direction of the Board of Directors as the chair
of the Apache DeltaSpike Project, and to have primary responsibility
for management of the projects within the scope of
responsibility of the Apache DeltaSpike Project; and be it further
RESOLVED, that the persons listed immediately below be and
hereby are appointed to serve as the initial members of the
Apache DeltaSpike Project:
Gerhard Petracek gpetracek at apache.org
Mark Struberg struberg at apache.org
Pete Muir pmuir at redhat.com
Jason Porter lightguard.jp at gmail.com
Shane Bryzak sbryzak at gmail.com
Rudy de Busscher rdebusscher at apache.org
Christian Kaltepoth christian at kaltepoth.de
Arne Limburg arne.limburg at openknowledge.de
Charles Moulliard cmoulliard at gmail.com
Cody Lerum cody.lerum at gmail.com
Romain Mannu-Buccau rmannibucau at gmail.com
Matthew Jason Benson mbenson at apache.org
Jim Jagielski jim at apache.org
David Blevins dblevins at apache.org
Ken Finnigan ken at kenfinnigan.me
John D. Ament johndament at apache.org
NOW, THEREFORE, BE IT FURTHER RESOLVED, that Mark Struberg
be appointed to the office of Vice President, Apache DeltaSpike, to
serve in accordance with and subject to the direction of the
Board of Directors and the Bylaws of the Foundation until
death, resignation, retirement, removal or disqualification,
or until a successor is appointed; and be it further
RESOLVED, that the initial Apache DeltaSpike PMC be and hereby is
tasked with the creation of a set of bylaws intended to
encourage open development and increased participation in the
Apache DeltaSpike Project; and be it further
RESOLVED, that the Apache DeltaSpike Project be and hereby
is tasked with the migration and rationalization of the Apache
Incubator DeltaSpike podling; and be it further
RESOLVED, that all responsibilities pertaining to the Apache
Incubator DeltaSpike podling encumbered upon the Apache Incubator
Project are hereafter discharged.
https://cwiki.apache.org/confluence/display/DeltaSpike/Graduation+Proposal
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
[ANNOUNCE] Release of Apache DeltaSpike 0.1 (incubating)
The Apache DeltaSpike team is pleased to announce the first release (v0.1-incubating). DeltaSpike consists of a number of portable CDI extensions that provide useful features for Java application developers. The goal of DeltaSpike is to create a de-facto standard of CDI-Extensions that is developed and maintained by the community. Apache DeltaSpike is available in the central Maven repository under Group ID org.apache.deltaspike.*. Release Notes: http://s.apache.org/DeltaSpike_01incubating With this first step we started to merge Apache MyFaces CODI-Core and JBoss Solder. We will release early and often. So take the chance and test the first features provided by this release. In the next release we will add further DeltaSpike-Core features and we will start with further modules. We would be happy to receive your feedback to improve Apache DeltaSpike step by step. Enjoy! Gerhard Petracek
Re: [VOTE] Release DeltaSpike 0.1-incubating
+1 regards, gerhard 2012/2/7 Gerhard Petracek gpetra...@apache.org Hi, This is the first incubator release for Apache DeltaSpike, with the artifacts being versioned as 0.1-incubating. We have received 16 binding +1 votes (including 4 votes of IPMC members) during the release voting on deltaspike-dev. Vote thread: http://s.apache.org/Ta2 Result: http://s.apache.org/8I3 Git release branch: http://s.apache.org/PbX (It will be pushed to our Apache Git repository after this vote passed.) Git release tag: http://s.apache.org/uC (It will be pushed to our Apache Git repository after this vote passed.) Release notes: http://s.apache.org/DeltaSpike_01incubating Release artifacts: http://s.apache.org/5hU PGP release file (key 2FDB81B1): http://s.apache.org/wW This vote is open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) Thanks, Gerhard
[RESULT] [VOTE] Release DeltaSpike 0.1-incubating
thank you for voting! 4 binding +1 votes (ipmc): - Matthias Wessendorf - Matt Benson - Mark Struberg - Gerhard Petracek no +0 and no -1 votes regards, gerhard 2012/2/7 Gerhard Petracek gpetra...@apache.org Hi, This is the first incubator release for Apache DeltaSpike, with the artifacts being versioned as 0.1-incubating. We have received 16 binding +1 votes (including 4 votes of IPMC members) during the release voting on deltaspike-dev. Vote thread: http://s.apache.org/Ta2 Result: http://s.apache.org/8I3 Git release branch: http://s.apache.org/PbX (It will be pushed to our Apache Git repository after this vote passed.) Git release tag: http://s.apache.org/uC (It will be pushed to our Apache Git repository after this vote passed.) Release notes: http://s.apache.org/DeltaSpike_01incubating Release artifacts: http://s.apache.org/5hU PGP release file (key 2FDB81B1): http://s.apache.org/wW This vote is open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) Thanks, Gerhard
Re: [VOTE] Apache BVal as a TLP
+1 regards, gerhard 2012/2/8 Mohammad Nour El-Din mn...@apache.org Hi... It has been discussed, since a while, about the graduation of Apache BVal, whether to graduate to a TLP or Subproject and whether it is time or not, [1], [2] and [3]. In the past few weeks there has been a [VOTE], [4], which formally discussed the graduation to a TLP project. Result announcement can be found here, [5]. It also has been decided to name the project Apache BVal [6]. The resolution charter content has been discussed and reviewed here [7]. *NOTE*: As per Niall's request, his name has been removed from the proposed PMC [8]. The Apache Bean Validation community sees it is time to request an IPMC [VOTE] on recommending this resolution [9] to the ASF board. Accordingly, would you please cast your vote: [ ] +1 to recommend Bean Validation's graduation [ ] 0 don't care [ ] -1 no, don't recommend yet, (because...) The vote will be open for 72 hours. [1] - http://s.apache.org/oTC [2] - http://s.apache.org/I8C [3] - http://s.apache.org/EQE [4] - http://s.apache.org/rU [5] - http://s.apache.org/7Sw [6] - http://s.apache.org/tY http://markmail.org/message/kzqgd7ff7t6p62va [7] - *http://s.apache.org/49R* [8] - http://s.apache.org/JYS [9] - See below: ## Resolution to create a TLP from graduating Incubator podling X. Establish the Apache BVal Project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to the Bean Validation Specification and its implementation as Apache BVal for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache BVal Project, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache BVal Project be and hereby is responsible for the creation and maintenance of software related to creating an implementation compliant with the Bean Validation Specification and a library of pre-developed validators and extensions; and be it further RESOLVED, that the office of Vice President, Apache BVal be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache BVal Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache BVal Project; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache BVal Project: - Albert Lee allee8...@apache.org - Carlos Vara Callau carlosv...@apache.org - David Jencks djen...@apache.org - Donald Woods dwo...@apache.org - Gerhard Petracek gpetra...@apache.org - Jeremy Bauer jrba...@apache.org - Kevan Lee Miller ke...@apache.org - Luciano Resende lrese...@apache.org - Matthias Wessendorf mat...@apache.org - Matthew Jason Benson mben...@apache.org - Mohammad Nour El-Din mn...@apache.org - Roman Stumm romanst...@apache.org - Simone Tripodi simonetrip...@apache.org - Mark Struberg strub...@apache.org NOW, THEREFORE, BE IT FURTHER RESOLVED, that Matthew Jason Benson be appointed to the office of Vice President, Apache BVal, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Apache BVal PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Apache BVal Project; and be it further RESOLVED, that the Apache BVal Project be and hereby is tasked with the migration and rationalization of the Apache Incubator Bean Validation podling; and be it further RESOLVED, that all responsibilities pertaining to the Apache Incubator Bean Validation podling encumbered upon the Apache Incubator Project are hereafter discharged. -- Thanks - Mohammad Nour Life is like riding a bicycle. To keep your balance you must keep moving - Albert Einstein
[VOTE] Release DeltaSpike 0.1-incubating
Hi, This is the first incubator release for Apache DeltaSpike, with the artifacts being versioned as 0.1-incubating. We have received 16 binding +1 votes (including 4 votes of IPMC members) during the release voting on deltaspike-dev. Vote thread: http://s.apache.org/Ta2 Result: http://s.apache.org/8I3 Git release branch: http://s.apache.org/PbX (It will be pushed to our Apache Git repository after this vote passed.) Git release tag: http://s.apache.org/uC (It will be pushed to our Apache Git repository after this vote passed.) Release notes: http://s.apache.org/DeltaSpike_01incubating Release artifacts: http://s.apache.org/5hU PGP release file (key 2FDB81B1): http://s.apache.org/wW This vote is open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) Thanks, Gerhard
Re: DeltaSpike IP clarifications
hi matt, imo we have to care about it in case of other external contributions we are going to get quite soon. however, in case of seam3 i don't see any issue at all. #1 redhat has a ccla on file #2 they contacted us [1] to join forces (and they found out that the asf is also a great place for them to do so) and they announced it as well [2] #3 their employees who wrote the original source-code do the initial import after we agreed on it from a technical point of view #4 basically there isn't a license issue at all, because the source-code is AL v2 licensed already (@our higher quality standard: see #1-#3) if we think that #1-#4 isn't enough, imo it's faster to ask redhat to write a formal letter that they grant us access explicitly. for sure that's just my personal opinion. regards, gerhard [1] http://goo.gl/u3ewl [2] http://planet.jboss.org/post/seam_next_announcement 2012/1/16 Matt Benson gudnabr...@gmail.com It may also be pertinent to note that the codebases here in question are also ALv2 licensed. Matt On Mon, Jan 16, 2012 at 1:49 PM, Matt Benson mben...@apache.org wrote: Hi, all--per [1], Generally, the mentors of a new project will need to consult with general@incubator.apache.org or the Apache legal team about the particular circumstances. So, here I am. The situation can be read in detail at [2], but in short is this: DeltaSpike is intended to amalgamate best of add-on solutions from the Java EE community with regard to the Contexts and Dependency Injection for the Java EE platform (CDI) specification. Thus its sources may incorporate code originating from numerous sources, but due to a number of reasons including e.g. anticipated feature overlap, it does not seem appropriate to include whole codebases under software grants. The specific question at the moment regards code to which Red Hat holds the copyright. The ASF has a filed CCLA from Red Hat, but I have been taking the position that we still need some form of assurance that code relating to CDI (primarily embodied in the Solder and Seam) projects is *specifically* approved for contribution to DeltaSpike. I'll present the basic question in multiple-choice form (with options shown in order of difficulty): What do we need to show provenance? a. Nothing. Stop being so damned paranoid. The CCLA is enough. b. DeltaSpike's Red Hat-employed committers' assurance that their employer is on board. c. A signed statement from Red Hat to the effect that their employees are authorized to contribute CDI-related code. d. A software grant for any codebase, even if we only intend to cherry-pick from it. e. Jim Whitehurst's eternal soul. f. Something else, namely _. Thanks, Matt on behalf of DeltaSpike [1] http://incubator.apache.org/guides/mentor.html#initial-ip-clearance [2] http://markmail.org/thread/g65yi42mdzvq5bu2
Re: DeltaSpike IP clarifications
hi, in general - fyi: we don't have a huge import. we discuss single features and if we agree on one, one of the members (of the original project) commits it. all authors have their icla on file, joined the project and participate in the discussion and the release votes. regards, gerhard 2012/1/17 Sam Ruby ru...@intertwingly.net On Tue, Jan 17, 2012 at 2:33 PM, ralph.goers @dslextreme.com ralph.go...@dslextreme.com wrote: I didn't mention CCLA's on purpose. A corporation will have a CCLA on file to either a) declare that certain employees are permitted to contribute software or b) declare that certain software is contributed to the ASF. A CCLA that is on file that only includes Schedule A doesn't grant the ASF permission to use specific software created by the company. If the company is donating the software they need to specify it. If the software is being contributed via an ICLA then the CCLA simply says the company is giving the contributor the right to contribute software that normally the company would own. However, an individual should never contribute software under their ICLA that they didn't author, unless they have explicit permission from the other authors. For a significant contribution a software grant is typically the best way to do it. I concur. Either an (additional|updated) CCLA with a concurrent software grant (Schedule B) for the code in question -or- simply a separate Software Grant would be appreciated. If RedHat is on board with this (and everything in this conversations indicated that that is indeed the case), then that shouldn't be a problem? - Sam Ruby - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: DeltaSpike IP clarifications
ok - matt and i just had a short talk with sam to ensure that we are talking about the same. it isn't the only way, but to resolve it once and for all it's easier to handle it via a software grant. @matt: it would be great if you can contact them again. @sam: thx for your help regards, gerhard 2012/1/17 Gerhard Petracek gpetra...@apache.org hi, in general - fyi: we don't have a huge import. we discuss single features and if we agree on one, one of the members (of the original project) commits it. all authors have their icla on file, joined the project and participate in the discussion and the release votes. regards, gerhard 2012/1/17 Sam Ruby ru...@intertwingly.net On Tue, Jan 17, 2012 at 2:33 PM, ralph.goers @dslextreme.com ralph.go...@dslextreme.com wrote: I didn't mention CCLA's on purpose. A corporation will have a CCLA on file to either a) declare that certain employees are permitted to contribute software or b) declare that certain software is contributed to the ASF. A CCLA that is on file that only includes Schedule A doesn't grant the ASF permission to use specific software created by the company. If the company is donating the software they need to specify it. If the software is being contributed via an ICLA then the CCLA simply says the company is giving the contributor the right to contribute software that normally the company would own. However, an individual should never contribute software under their ICLA that they didn't author, unless they have explicit permission from the other authors. For a significant contribution a software grant is typically the best way to do it. I concur. Either an (additional|updated) CCLA with a concurrent software grant (Schedule B) for the code in question -or- simply a separate Software Grant would be appreciated. If RedHat is on board with this (and everything in this conversations indicated that that is indeed the case), then that shouldn't be a problem? - Sam Ruby - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Recommend graduating Apache Bean-Validation (BVAL) as a TLP
+1 regards, gerhard 2012/1/8 Mark Struberg strub...@yahoo.de Dear IPMC, dear Community! The Apache Bean-Validation project provides an ALv2 licensed implementation of the JSR-303 Bean Validation Specification and would like to start a VOTE on graduating as a TLP. The podling is in the incubator since 2010 and successfully shipped 3 releases and established an active community. The internal PPMC VOTE has decided with 11 +1 (see [1]) that we would like to propose graduation as a TLP. We also went through the graduation checklist and made sure that we fulfilled all requirements. We would like to thank our Mentors and the board for their continued support and also Roman Stumm and his team for contributing this project to the ASF! We are happy to finally start the VOTE about the recommendation to the board about graduating BVAL to a TLP with the Board Resolution Report attached below. For better readability, the Resolution text is also available in our WIKI [2] Please VOTE on recommending BVAL as a TLP [+1] graduate BVAL as a TLP [+0] don't care [-1] nope, because (fill in) The VOTE is open for 72h. Incubator Page : http://incubator.apache.org/bval Status Page: http://incubator.apache.org/projects/beanvalidation.html thanks, the BVAL PPMC Board Resolution Report -- WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to creating an implementation compliant with JSR-303 and a library of pre-developed validators and extensions for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Bean Validation Project, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Bean Validation Project be and hereby is responsible for the creation and maintenance of software related to creating an implementation compliant with JSR-303 and a library of pre-developed validators and extensions; and be it further RESOLVED, that the office of Vice President, Apache Bean Validation be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache Bean Validation Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Bean Validation Project; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Bean Validation Project: * Albert Lee allee8...@apache.org * Carlos Vara Callau carlosv...@apache.org * David Jencks djen...@apache.org * Donald Woods dwo...@apache.org * Gerhard Petracek gpetra...@apache.org * Jeremy Bauer jrba...@apache.org * Kevan Lee Miller ke...@apache.org * Luciano Resende lrese...@apache.org * Matthias Wessendorf mat...@apache.org * Matthew Jason Benson mben...@apache.org * Mohammad Nour El-Din mn...@apache.org * Niall Pemberton nia...@apache.org * Roman Stumm romanst...@apache.org * Simone Tripodi simonetrip...@apache.org * Mark Struberg strub...@apache.org NOW, THEREFORE, BE IT FURTHER RESOLVED, that Matthew Jason Benson be appointed to the office of Vice President, Apache Bean Validation, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Apache Bean Validation PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Apache Bean Validation Project; and be it further RESOLVED, that the Apache Bean Validation Project be and hereby is tasked with the migration and rationalization of the Apache Incubator Bean Validation podling; and be it further RESOLVED, that all responsibilities pertaining to the Apache Incubator Bean Validation podling encumbered upon the Apache Incubator Project are hereafter discharged. [1] http://mail-archives.apache.org/mod_mbox/incubator-bval-dev/20.mbox/%3CCAOvkMoZ6EVNDZ2SNq44L992JTr_oquoJV2Oun-fKhpYX03DPiQ%40mail.gmail.com%3E [2] https://cwiki.apache.org/confluence/display/BeanValidation/Graduation+Proposal - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Result (was: Re: [VOTE] DeltaSpike to join the Incubator)
we received a moderated e-mail after we closed the vote. it was sent during the voting phase - updated result: thank you for voting! 8 binding +1 votes (ipmc): - Mark Struberg - Jim Jagielski - Matt Benson - Matthias Wessendorf - Christian Grobmeier - Gurkan Erdogdu - David Blevins - Gerhard Petracek 3 non-binding +1 votes: - Joey Echeverria - Bart Kummel - Francis De Brabandere no -1 votes regards, gerhard 2011/12/7 Gerhard Petracek gpetra...@apache.org one vote wasn't listed - corrected result: thank you for voting! 7 binding +1 votes (ipmc): - Mark Struberg - Jim Jagielski - Matt Benson - Matthias Wessendorf - Christian Grobmeier - Gurkan Erdogdu - Gerhard Petracek 3 non-binding +1 votes: - Joey Echeverria - Bart Kummel - Francis De Brabandere no -1 votes regards, gerhard 2011/12/7 Gerhard Petracek gpetra...@apache.org thank you for voting! 6 binding +1 votes (ipmc): - Mark Struberg - Matt Benson - Matthias Wessendorf - Christian Grobmeier - Gurkan Erdogdu - Gerhard Petracek 3 non-binding +1 votes: - Joey Echeverria - Bart Kummel - Francis De Brabandere no -1 votes regards, gerhard 2011/12/4 Gerhard Petracek gpetra...@apache.org Hello, Please vote on the acceptance of DeltaSpike into the Apache Incubator. The proposal is available at [1] and its content is also included below for your convenience. Please vote: [ ] +1 Accept DeltaSpike for incubation [ ] +0 Don't care [ ] -1 Don't accept DeltaSpike for incubation because... The vote is open for 72 hours. Thanks, Gerhard [1] http://wiki.apache.org/incubator/DeltaSpikeProposal Apache DeltaSpike Proposal == Abstract Apache DeltaSpike is a collection of JSR-299 (CDI) Extensions for building applications on the Java SE and EE platforms. Proposal Apache DeltaSpike will consist of a number of portable CDI extensions that provide useful features for Java application developers. The goal of Apache DeltaSpike is to create a de-facto standard of extensions that is developed and maintained by the Java community, and to act as an incubator for features that may eventually become part of the various Java SE and EE-related specifications. Background One of the most exciting inclusions of the Java EE6 specification is JSR-299, Contexts and Dependency Injection (CDI) for Java. CDI builds on other Java EE specifications by defining a contextual component model and typesafe dependency injection framework for managed beans. It also defines a SPI that allows developers to write portable “extensions” that can be used to modify the behaviour of the Java EE platform, by offering additional features not provided by the platform by default. Apache DeltaSpike builds on this portable extensions SPI by providing baseline utilities and CDI Extensions which form the base of almost all CDI applications. Rationale There presently exists a number of open source projects that provide extensions for CDI, such as Apache MyFaces CODI, JBoss Seam3 and CDISource. Apache DeltaSpike seeks to unify these efforts by creating an “industry standard” set of extensions, combining the best core features of these projects. The project also aims to provide a rich, JBoss Arquillian based (license: ALv2), test environment to ensure that DeltaSpike portably runs in all important CDI environments. Initial Goals The initial goals of the Apache DeltaSpike project are to: * Setup the governance structure of the project * Receive code donations from contributing members * Ensure all donated code is appropriately licensed under the Apache License * Merge and rename code to reflect new project name * Merge code where feature overlap exists * Merge or produce documentation for all modules * Provide simple examples demonstrating feature usage * Produce release/s based on a schedule created by the PMC * Attract contributions from the greater Java EE community and other Java EE development groups Current Status The initial codebase for Apache DeltaSpike will be populated with mature code donations from project members, including JBoss Seam3, Apache MyFaces CODI and CDISource. Meritocracy All contributors have a well established history in the open source community and are well aware of the meritocracy principles of the Apache Software Foundation. Currently the Seam3 project is fortunate to receive the majority of its code contributions from its large community of users. Many of the modules that are contained in the Seam project are led by volunteers from the community, who have both direct commit access, and discretion over the direction of their modules. Apache MyFaces CODI is a subproject of Apache MyFaces and thus all contributors are already
Result (was: Re: [VOTE] DeltaSpike to join the Incubator)
thank you for voting! 6 binding +1 votes (ipmc): - Mark Struberg - Matt Benson - Matthias Wessendorf - Christian Grobmeier - Gurkan Erdogdu - Gerhard Petracek 3 non-binding +1 votes: - Joey Echeverria - Bart Kummel - Francis De Brabandere no -1 votes regards, gerhard 2011/12/4 Gerhard Petracek gpetra...@apache.org Hello, Please vote on the acceptance of DeltaSpike into the Apache Incubator. The proposal is available at [1] and its content is also included below for your convenience. Please vote: [ ] +1 Accept DeltaSpike for incubation [ ] +0 Don't care [ ] -1 Don't accept DeltaSpike for incubation because... The vote is open for 72 hours. Thanks, Gerhard [1] http://wiki.apache.org/incubator/DeltaSpikeProposal Apache DeltaSpike Proposal == Abstract Apache DeltaSpike is a collection of JSR-299 (CDI) Extensions for building applications on the Java SE and EE platforms. Proposal Apache DeltaSpike will consist of a number of portable CDI extensions that provide useful features for Java application developers. The goal of Apache DeltaSpike is to create a de-facto standard of extensions that is developed and maintained by the Java community, and to act as an incubator for features that may eventually become part of the various Java SE and EE-related specifications. Background One of the most exciting inclusions of the Java EE6 specification is JSR-299, Contexts and Dependency Injection (CDI) for Java. CDI builds on other Java EE specifications by defining a contextual component model and typesafe dependency injection framework for managed beans. It also defines a SPI that allows developers to write portable “extensions” that can be used to modify the behaviour of the Java EE platform, by offering additional features not provided by the platform by default. Apache DeltaSpike builds on this portable extensions SPI by providing baseline utilities and CDI Extensions which form the base of almost all CDI applications. Rationale There presently exists a number of open source projects that provide extensions for CDI, such as Apache MyFaces CODI, JBoss Seam3 and CDISource. Apache DeltaSpike seeks to unify these efforts by creating an “industry standard” set of extensions, combining the best core features of these projects. The project also aims to provide a rich, JBoss Arquillian based (license: ALv2), test environment to ensure that DeltaSpike portably runs in all important CDI environments. Initial Goals The initial goals of the Apache DeltaSpike project are to: * Setup the governance structure of the project * Receive code donations from contributing members * Ensure all donated code is appropriately licensed under the Apache License * Merge and rename code to reflect new project name * Merge code where feature overlap exists * Merge or produce documentation for all modules * Provide simple examples demonstrating feature usage * Produce release/s based on a schedule created by the PMC * Attract contributions from the greater Java EE community and other Java EE development groups Current Status The initial codebase for Apache DeltaSpike will be populated with mature code donations from project members, including JBoss Seam3, Apache MyFaces CODI and CDISource. Meritocracy All contributors have a well established history in the open source community and are well aware of the meritocracy principles of the Apache Software Foundation. Currently the Seam3 project is fortunate to receive the majority of its code contributions from its large community of users. Many of the modules that are contained in the Seam project are led by volunteers from the community, who have both direct commit access, and discretion over the direction of their modules. Apache MyFaces CODI is a subproject of Apache MyFaces and thus all contributors are already familiar with the meritocracy principles. The CDISource project has adopted the principles of meritocracy by the founding developers having control of different modules depending on their contribution to those modules. Community The JBoss Seam, Apache MyFaces CODI and CDISource projects already have well established communities, consisting of many active users and contributors. One of the primary goals of the Apache DeltaSpike project is to unify this community, and by creating a project that is a “single source of truth” for CDI Extensions. By doing this, we hope to make the whole greater than the sum of its parts, i.e. to attract a much stronger community than that which currently exists across the separate projects. To this end, it is a goal of this project to attract contributors from the Java EE community in addition to those from the three projects
Re: Result (was: Re: [VOTE] DeltaSpike to join the Incubator)
one vote wasn't listed - corrected result: thank you for voting! 7 binding +1 votes (ipmc): - Mark Struberg - Jim Jagielski - Matt Benson - Matthias Wessendorf - Christian Grobmeier - Gurkan Erdogdu - Gerhard Petracek 3 non-binding +1 votes: - Joey Echeverria - Bart Kummel - Francis De Brabandere no -1 votes regards, gerhard 2011/12/7 Gerhard Petracek gpetra...@apache.org thank you for voting! 6 binding +1 votes (ipmc): - Mark Struberg - Matt Benson - Matthias Wessendorf - Christian Grobmeier - Gurkan Erdogdu - Gerhard Petracek 3 non-binding +1 votes: - Joey Echeverria - Bart Kummel - Francis De Brabandere no -1 votes regards, gerhard 2011/12/4 Gerhard Petracek gpetra...@apache.org Hello, Please vote on the acceptance of DeltaSpike into the Apache Incubator. The proposal is available at [1] and its content is also included below for your convenience. Please vote: [ ] +1 Accept DeltaSpike for incubation [ ] +0 Don't care [ ] -1 Don't accept DeltaSpike for incubation because... The vote is open for 72 hours. Thanks, Gerhard [1] http://wiki.apache.org/incubator/DeltaSpikeProposal Apache DeltaSpike Proposal == Abstract Apache DeltaSpike is a collection of JSR-299 (CDI) Extensions for building applications on the Java SE and EE platforms. Proposal Apache DeltaSpike will consist of a number of portable CDI extensions that provide useful features for Java application developers. The goal of Apache DeltaSpike is to create a de-facto standard of extensions that is developed and maintained by the Java community, and to act as an incubator for features that may eventually become part of the various Java SE and EE-related specifications. Background One of the most exciting inclusions of the Java EE6 specification is JSR-299, Contexts and Dependency Injection (CDI) for Java. CDI builds on other Java EE specifications by defining a contextual component model and typesafe dependency injection framework for managed beans. It also defines a SPI that allows developers to write portable “extensions” that can be used to modify the behaviour of the Java EE platform, by offering additional features not provided by the platform by default. Apache DeltaSpike builds on this portable extensions SPI by providing baseline utilities and CDI Extensions which form the base of almost all CDI applications. Rationale There presently exists a number of open source projects that provide extensions for CDI, such as Apache MyFaces CODI, JBoss Seam3 and CDISource. Apache DeltaSpike seeks to unify these efforts by creating an “industry standard” set of extensions, combining the best core features of these projects. The project also aims to provide a rich, JBoss Arquillian based (license: ALv2), test environment to ensure that DeltaSpike portably runs in all important CDI environments. Initial Goals The initial goals of the Apache DeltaSpike project are to: * Setup the governance structure of the project * Receive code donations from contributing members * Ensure all donated code is appropriately licensed under the Apache License * Merge and rename code to reflect new project name * Merge code where feature overlap exists * Merge or produce documentation for all modules * Provide simple examples demonstrating feature usage * Produce release/s based on a schedule created by the PMC * Attract contributions from the greater Java EE community and other Java EE development groups Current Status The initial codebase for Apache DeltaSpike will be populated with mature code donations from project members, including JBoss Seam3, Apache MyFaces CODI and CDISource. Meritocracy All contributors have a well established history in the open source community and are well aware of the meritocracy principles of the Apache Software Foundation. Currently the Seam3 project is fortunate to receive the majority of its code contributions from its large community of users. Many of the modules that are contained in the Seam project are led by volunteers from the community, who have both direct commit access, and discretion over the direction of their modules. Apache MyFaces CODI is a subproject of Apache MyFaces and thus all contributors are already familiar with the meritocracy principles. The CDISource project has adopted the principles of meritocracy by the founding developers having control of different modules depending on their contribution to those modules. Community The JBoss Seam, Apache MyFaces CODI and CDISource projects already have well established communities, consisting of many active users and contributors. One of the primary goals of the Apache DeltaSpike project is to unify this community
[VOTE] DeltaSpike to join the Incubator
Sabot-Durand (Independent contributor) * Pete Royle (Independent contributor) * Mark Struberg (individual, ASF member) * Gerhard Petracek (individual, ASF member) * David Blevins (individual, ASF member) * Matthias Wessendorf (individual, ASF member) * Jakob Korherr (individual, ASF committer) * Andy Gibson (Independent contributor) * Rick Hightower (Independent contributor) * Rob Williams (Independent contributor) Alignment The Apache DeltaSpike project is intended to be portable, and be fully compatible with any compliant Java EE6 container. To promote the adoption of this project, we believe that it is important that it remains free from corporate association and is perceived by the community to be vendor neutral. To this end, the Apache Software Foundation with its values of transparency and community makes it an excellent fit for this project, not to mention that one of the contributing members (Apache MyFaces CODI) is already an Apache project. Known Risks While many of the contributors to the Apache DeltaSpike project are volunteers, the initial effort of setting up the project and driving ongoing releases may fall to corporate-sponsored members. It is recognized that there may be a slight risk based on the dependence of salaried contributors, however it can safely be said that most if not all of these contributors began as community volunteers that recognized the merit of the project and began contributing as a result of their own passion. Documentation Documentation for the existing projects can be found as follows: * JBoss Seam - http://docs.jboss.org/seam/3/latest/reference/en-US/html/ * Apache MyFaces CODI - https://cwiki.apache.org/confluence/display/EXTCDI/Documentation * CDISource - http://cdisource.org/site/ Documentation for the Apache DeltaSpike project would be created by combining and editing material from the above sources, in addition to the writing of new material where required. Initial Source Source code contributions for the Apache DeltaSpike project would be made from its member projects, and the initial goal would be to provide a common core extension which contains a number of features considered essential for building other extensions. Tests for this common core will be developed using the Arquillian integration testing framework, allowing the extension to be automatically tested extensively across various CDI implementations and EE servers in the interest of providing a stable foundation for building other extensions. The ongoing goal of the project will be to gradually incorporate additional features as determined by the PPMC, extending on the foundation features provided by the common core. Source and IP Submission Plan The following resources will be moved to Apache infrastructure under the Apache DeltaSpike project name: * Core JBoss Seam 3 codebase. Seam 3 is already licensed under the Apache License V2. * Seam Core Reference Documentation * Apache MyFaces CODI codebase * Apache MyFaces CODI documentation * CDISource codebase under the Apache License V2 The existing Seam, MyFaces CODI and CDISource trademarks will be retained by their respective owners. External Dependencies The following external dependencies have been identified: * Apache Maven - Java based build tool - Apache License 2.0, (non-runtime) * Arquillian - Java EE integration testing framework - Apache License 2.0, (non-runtime) * Shrinkwrap - Java deployment packaging - Apache License 2.0 (non-runtime) * various Java EE API packages - all Apache License 2.0 (non-runtime) Required Resources -- Mailing Lists * deltaspike-us...@incubator.apache.org * deltaspike-...@incubator.apache.org * deltaspike-comm...@incubator.apache.org * deltaspike-priv...@incubator.apache.org Version Control It is proposed that the source code for the Apache DeltaSpike project be hosted in the Apache Git repository, under the following directory: * incubator/deltaspike/ Issue Tracking The following JIRA project would be required to track issues for the Apache DeltaSpike project: * DELTASPIKE Initial Committers * Shane Bryzak (sbryzak at gmail.com) * Jason Porter (lightguard.jp at gmail.com) * Stuart Douglas (stuart.w.douglas at gmail.com) * Jozef Hartinger (jozefhartinger at gmail.com) * Brian Leathem (bleathem at gmail.com) * Ken Finnigan (ken at kenfinnigan.me) * Marius Bogoevici (mariusb at redhat.com) * George Gastaldi (gegastaldi at gmail.com) * John Ament (john.d.ament at gmail.com) * Cody Lerum (cody.lerum at clearfly.net) * Antoine Sabot-Durand (antoine at sabot-durand.net) * Pete Royle (pete at screamingcoder.com) * Pete Muir (pmuir at redhat.com) * Mark Struberg
Re: [VOTE] DeltaSpike to join the Incubator
+1 (binding) regards, gerhard 2011/12/4 Gerhard Petracek gpetra...@apache.org Hello, Please vote on the acceptance of DeltaSpike into the Apache Incubator. The proposal is available at [1] and its content is also included below for your convenience. Please vote: [ ] +1 Accept DeltaSpike for incubation [ ] +0 Don't care [ ] -1 Don't accept DeltaSpike for incubation because... The vote is open for 72 hours. Thanks, Gerhard [1] http://wiki.apache.org/incubator/DeltaSpikeProposal Apache DeltaSpike Proposal == Abstract Apache DeltaSpike is a collection of JSR-299 (CDI) Extensions for building applications on the Java SE and EE platforms. Proposal Apache DeltaSpike will consist of a number of portable CDI extensions that provide useful features for Java application developers. The goal of Apache DeltaSpike is to create a de-facto standard of extensions that is developed and maintained by the Java community, and to act as an incubator for features that may eventually become part of the various Java SE and EE-related specifications. Background One of the most exciting inclusions of the Java EE6 specification is JSR-299, Contexts and Dependency Injection (CDI) for Java. CDI builds on other Java EE specifications by defining a contextual component model and typesafe dependency injection framework for managed beans. It also defines a SPI that allows developers to write portable “extensions” that can be used to modify the behaviour of the Java EE platform, by offering additional features not provided by the platform by default. Apache DeltaSpike builds on this portable extensions SPI by providing baseline utilities and CDI Extensions which form the base of almost all CDI applications. Rationale There presently exists a number of open source projects that provide extensions for CDI, such as Apache MyFaces CODI, JBoss Seam3 and CDISource. Apache DeltaSpike seeks to unify these efforts by creating an “industry standard” set of extensions, combining the best core features of these projects. The project also aims to provide a rich, JBoss Arquillian based (license: ALv2), test environment to ensure that DeltaSpike portably runs in all important CDI environments. Initial Goals The initial goals of the Apache DeltaSpike project are to: * Setup the governance structure of the project * Receive code donations from contributing members * Ensure all donated code is appropriately licensed under the Apache License * Merge and rename code to reflect new project name * Merge code where feature overlap exists * Merge or produce documentation for all modules * Provide simple examples demonstrating feature usage * Produce release/s based on a schedule created by the PMC * Attract contributions from the greater Java EE community and other Java EE development groups Current Status The initial codebase for Apache DeltaSpike will be populated with mature code donations from project members, including JBoss Seam3, Apache MyFaces CODI and CDISource. Meritocracy All contributors have a well established history in the open source community and are well aware of the meritocracy principles of the Apache Software Foundation. Currently the Seam3 project is fortunate to receive the majority of its code contributions from its large community of users. Many of the modules that are contained in the Seam project are led by volunteers from the community, who have both direct commit access, and discretion over the direction of their modules. Apache MyFaces CODI is a subproject of Apache MyFaces and thus all contributors are already familiar with the meritocracy principles. The CDISource project has adopted the principles of meritocracy by the founding developers having control of different modules depending on their contribution to those modules. Community The JBoss Seam, Apache MyFaces CODI and CDISource projects already have well established communities, consisting of many active users and contributors. One of the primary goals of the Apache DeltaSpike project is to unify this community, and by creating a project that is a “single source of truth” for CDI Extensions. By doing this, we hope to make the whole greater than the sum of its parts, i.e. to attract a much stronger community than that which currently exists across the separate projects. To this end, it is a goal of this project to attract contributors from the Java EE community in addition to those from the three projects already mentioned. Core Developers * Shane Bryzak (Red Hat) * Jason Porter (Red Hat) * Stuart Douglas (Red Hat) * Jozef Hartinger (Red Hat) * Brian Leathem (Red Hat) * Ken Finnigan (Red Hat) * Marius
