Re: [PROPOSAL] Apache DeltaSpike - CDI-Extensions project
+1 (binding) On Wed, Nov 30, 2011 at 9:53 PM, Matthias Wessendorf mat...@apache.orgwrote: On Wed, Nov 30, 2011 at 5:55 PM, Mark Struberg strub...@yahoo.de wrote: yup the [VOTE] mail is currently planed for next monday. I will interpret any +1 as a frenetic 'wooohooo ye' until then ;) +1 :) LieGrue, strub - Original Message - From: Matt Benson gudnabr...@gmail.com To: general@incubator.apache.org Cc: Sent: Wednesday, November 30, 2011 5:28 PM Subject: Re: [PROPOSAL] Apache DeltaSpike - CDI-Extensions project Mmm, shouldn't voting be carried out in a separate [VOTE] Accept DeltaSpike... thread? Matt On Wed, Nov 30, 2011 at 10:21 AM, Matthias Wessendorf mat...@apache.org wrote: +1 (binding) -Matthias On Wed, Nov 30, 2011 at 1:24 PM, Jim Jagielski j...@jagunet.com wrote: +1 (binding) PS: Updated the proposal to re-add myself as Mentor... On Nov 29, 2011, at 6:40 PM, Mark Struberg wrote: Hi! JBoss, The Apache MyFaces CODI team and CDISource would like to propose the Apache DeltaSpike project to the Incubator. We have added the initial proposal to the Wiki[1] and its content is also included below for convenience. There are already a few people who expressed interest in contributing additional CDI Extensions and would like to join this effort. Of course, we are thankful for every helping hand! We are looking forward to feedback and/or questions on the proposal. We already have five mentors, but would very much welcome additional volunteers to help steer Apache DeltaSpike through the incubation process. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf - 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 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Thanks - Mohammad Nour Life is like riding a bicycle. To keep your balance you must keep moving - Albert Einstein
Re: [VOTE] DeltaSpike to join the Incubator
+1 (binding) On Wed, Dec 7, 2011 at 8:26 PM, David Blevins david.blev...@gmail.comwrote: +1 (binding) On Dec 4, 2011, at 2:11 PM, Gerhard Petracek wrote: 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
Re: [RESULT][VOTE] Release ace version 0.8.1-incubator subprojects
Time to call the vote on the ace version 0.8.1-incubator subprojects releases. As we didn't get any additional votes, I'm going to close this vote with the original results from the dev list as follows, * +1 votes from Marcel Offermans***, Jean-Baptiste Onofré***, Toni Menzel*, Bram de Kruijff, Angelo van der Sijpt*, Carsten Ziegeler***, and Karl Pauls***. * No other votes As we have 4 binding IPMC +1, the vote is successful. I'll make the artifacts available as soon as possible. * == PPMC ** == IPMC *** == PPMC + IPMC - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[DISCUSS] Proposed resolution: Establish the Apache ACE Project
In preparation [1] of a vote to propose that the IPMC recommends this resolution to the board, I am posting the resolution that was drawn up by the ACE community and its mentors. Please provide feedback so we can finalize its wording. [1] http://incubator.apache.org/guides/graduation.html#ipmc-top-level-recommendation Greetings, Marcel X. Establish the Apache ACE 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 management and deployment of OSGi based and other software artifacts 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 ACE Project, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache ACE Project be and hereby is responsible for the creation and maintenance of software related to the management and deployment of OSGi based and other software artifacts; and be it further RESOLVED, that the office of Vice President, Apache ACE 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 ACE Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache ACE 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 ACE Project: * Angelo van der Sijpt ange...@apache.org * Brian Toppingbtopp...@apache.org * Clement Escoffierclem...@apache.org * Carsten Ziegeler cziege...@apache.org * Jean-Baptiste Onofre jbono...@apache.org * Karl Pauls kpa...@apache.org * Marcel Offermans ma...@apache.org * Toni Menzel to...@apache.org NOW, THEREFORE, BE IT FURTHER RESOLVED, that Marcel Offermans be appointed to the office of Vice President, Apache ACE, 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 ACE 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 ACE Project; and be it further RESOLVED, that the Apache ACE Project be and hereby is tasked with the migration and rationalization of the Apache Incubator ACE podling; and be it further RESOLVED, that all responsibilities pertaining to the Apache Incubator ACE podling encumbered upon the Apache Incubator Project are hereafter discharged.
Re: [PROPOSAL] Apache Bloodhound
Marvin Humphrey wrote on Sat, Dec 10, 2011 at 10:55:39 -0800: On Sat, Dec 10, 2011 at 12:22:28PM -0500, Greg Stein wrote: There are three types of code that will go into the final Apache Bloodhound release: 1) the original stuff from Edgewall 2) the pre-packaged popular plugins from third-parties 3) original code committed here at the ASF The code under (1) will have its original BSD license. The code from (2) will have its license, or it may be ALv2 if we get SGAs from those developers. And, of course, all code under (3) will be under ALv2. Presumably there will be significant modifications to the BSD codebase by Apache contributors as time goes along. If these modifications fall under the ALv2, then files with a BSD license header will contain a mix of ALv2 and BSD code. Short of maintaining our contributions as diffs :) how are we to communicate which parts of the files fall under BSD and which parts fall under ALv2? Do we need to, or can we simply say Portions of this file are BSD and portions ALv2? Daniel (plus, _somebody_ is going to mention that using 'svn blame' and 'svn cat file.c@LAST_REVISION_OF_CODE_IMPORT' is an option...) I have not yet been able to find clear guidance in the existing dev documentation. http://www.apache.org/legal/src-headers.html#3party 4. Minor modifications/additions to third-party source files should typically be licensed under the same terms as the rest of the rest of the third-party source for convenience. 5. Major modifications/additions to third-party should be dealt with on a case-by-case basis by the PMC. There are certainly numerous precedents for bundling of BSD code with Apache products, and it is not hard to understand how minor patches here and there would work as contributions implicitly licensed under the upstream license. But are there any precedents for handling major mods? Marvin Humphrey - 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
