Re: Possible ASF Incubator Project transfer..

[David Blevins]

The procedure would be identical to the OpenOffice donation from Oracle to
Apache.  Oracle would have to sign a software grant to Apache and
contributors would have to iCLAs. Apache requires copyright owners to vouch
they are the original authors and have given permission for their IP to be
licensed under the Apache Software License.

It would not be possible to "fork" to Apache without sign-off from Oracle.


-David

On Thu, Mar 3, 2016 at 12:17 PM, Martin Gainty  wrote:

> Looking for procedures for transferring control of currently un-maintained
> glassfish J2EE Server from Oracle to ASF incubator project
>
> Thanks and Regards
> Martin Gainty
>
>
> Subject: Re: [gf-users] Re: Farewell to Oracle
> To: mgai...@hotmail.com
> From: reza_rah...@lycos.com
> Date: Thu, 3 Mar 2016 13:56:02 -0500
>
>
>
>
>
>
> That sounds just about right. How can I
>   get involved?
>
>
>
>   On 3/3/2016 1:53 PM, Martin Gainty wrote:
>
>
>
>
>   Feel free to join Marcus and myself to transfer
> Glassfish to ASF  ..
>
>
>
>
>
>
>   > To: us...@glassfish.java.net
>
> > From: reza_rah...@lycos.com
>
> > Date: Thu, 3 Mar 2016 12:51:49 -0500
>
> > Subject: [gf-users] Farewell to Oracle
>
> >
>
> > Folks,
>
> >
>
> > I am leaving Oracle behind on Friday. I have no doubt
> whatsoever that
>
> > this was one of the top five hardest decisions of my
> life. I am also at
>
> > this stage equally certain that this is the way I
> personally can best
>
> > help continue to advance the Java and Java EE
> communities. I will be
>
> > resuming the community work I have been part of for the
> better part of a
>
> > decade in earnest as soon as possible post-Oracle.
>
> >
>
> > At Oracle folks like my colleagues David Delabassee and
> Bruno Borges
>
> > will continue their roles in the Java EE ecosystem. I
> certainly wish the
>
> > many good folks at Oracle nothing but the best of luck.
> They have a very
>
> > hard job to do and they will continue to need our
> support, perhaps now
>
> > more than ever.
>
> >
>
> > As always anyone is absolutely welcome to reach out to
> me on just about
>
> > anything. Below are all my contact points.
>
> >
>
> > Cheers,
>
> > Reza
>
> >
>
> > Email: reza_rah...@lycos.com
>
> > Cell: 717-329-8149
>
> > Home Office: 215-736-1208
>
> > Google/Skype: m.reza.rahman
>
> > Twitter: @reza_rahman
>
> > https://www.linkedin.com/in/javareza
>
> > http://blog.rahmannet.net/
>
> > http://cargotracker.java.net
>
>
>
>
>
>
>

Re: [VOTE] Apache Tamaya for Incubation

[David Blevins]

+1

On Thu, Nov 13, 2014 at 9:56 AM, Gerhard Petracek gpetra...@apache.org
wrote:

 +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: Re: [DISCUSS] New Incubator Project for Enterprise Configuration

[David Blevins]

I'm happy to champion and endorse for inclusion in the Incubator as long as
the foremost focus is creating a functioning, lasting and healthy ASF
community and any JSR/JCP points always second.

I do not think these goals are mutually exclusive, in fact I think the
opposite; the world could benefit from JSRs based on and/or run by strong
Apache communities.

Provided it's the community leading the JSR and not the JSR leading the
community, I think we're a go for Incubation.


-David


On Mon, Nov 3, 2014 at 1:53 PM, Anatole Tresch atsti...@gmail.com wrote:

 Thanks Jean-Louis.
 I am sure there is enough work where you can help us ;)


 2014-11-03 22:13 GMT+01:00 Jean-Louis MONTEIRO jeano...@gmail.com:

  Thanks Anatole.
  You were the one pushing the JSR so I wanted to be sure about the purpose
  of this proposal.
  Sound very interesting to me.
 
  Looking forward to help if needed.
 
  Jean-Louis
 
  2014-11-03 18:18 GMT+01:00 Tresch, Anatole 
  anatole.tre...@credit-suisse.com
  :
 
   Hi Jean-Louis
  
   unfortunately I was a bit deferred in receiving this mail thread here.
 So
   sorry for the delay ;)
  
I do think it's an interested and important topic.
   
Was wondering what's Anatole position as the Configuration JSR as
 been
deferred from Java EE 8.
   This JSR was targeting mainly EE 8 and mostly deployment aspects. I
  think,
   with enough momentum,
   we could try to discuss of add some kind of SPIs to EE 8 through the
   umbrella JSR.
   On the other side, when we get a restful container management API, we
   could also
   use this to plugin with any kind of configuration solution. Of course,
 my
   hope is
   that we will be able to have a configuration solution in place that is
   mature and flexible
   enough to effectively support these EE scenarios.
   Application configuration basically is partially covered by Deltaspike
 as
   of now, but I think
   more features would be useful. As of now there is no good place to do a
   standardization
   for app config. I will try to revitalize the configuration stream in
 CDI,
   so we could at
   least end up in some kind of EE8 specification appendix. As of now this
   seems to be the
   maximum we can do on a standardization level. On the other side I
 think,
   Apache is a
   great chance to further evolve the concepts, so we will have a good
   chance, that we
   can standardize them at a later point.
  
Even if Mark and Gerhard are also part of DeltaSpike, that'd be great
  to
avoid having many different configuration projects in Apache and then
splitting forces.
Probably also a good opportunity to move commons-configuration from
proper/dormant.
   
Jean-Louis
  
   Fair enough. I am looking forward for any kind of collaboration here
  
   -Anatole
  
   Anatole Tresch
   Platform Strategy  Strategic Projects, KGVX 42
   +41 44 334 03 89 (*414 0389)
  
  
 
 
  --
  Jean-Louis
 



 --
 *Anatole Tresch*
 Java Engineer  Architect, JSR Spec Lead
 Glärnischweg 10
 CH - 8620 Wetzikon

 *Switzerland, Europe Zurich, GMT+1*
 *Twitter:  @atsticks*
 *Blogs: **http://javaremarkables.blogspot.ch/
 http://javaremarkables.blogspot.ch/*

 *Google: atsticksMobile  +41-76 344 62 79*

Re: [VOTE] fleece as new incubator project

[David Blevins]

+1 (binding)


-David

On Jun 6, 2014, at 12:31 AM, Romain Manni-Bucau rmannibu...@gmail.com wrote:

 Following the discussion earlier, I'm calling a vote to accept Fleece as a
 new Incubator project.
 
 The proposal draft is available at:
 https://wiki.apache.org/incubator/Fleece, and is also included  below.
 
 Vote is open for at least 72h and closes at the earliest on 09 June 09:30
 GMT.
 
 [ ] +1 accept Fleece in the Incubator
 [ ] +/-0
 [ ] -1 because...
 
 Here's my +1.
 
 
 Apache Fleece Proposal
 
 Abstract
 
 Apache Fleece is an implementation of JSR-353 (JavaTM API for JSON
 Processing).
 
 Proposal
 
 Apache Fleece will consist of a number of modules. Mainly an implementation
 of JSR-353 but also a set of usefule modules to help with the usage of
 JSR-353 (surely a mapping module and a jaxrs provider module).
 
 Background
 
 JSon being more and more important JavaEE 7 specified an API to read and
 create JSon objects/arrays.
 
 Apache Fleece builds on this specification a potential base to do Json at
 Apache (hopefully it will be integrated with CXF for instance).
 
 Rationale
 
 There is not yet a Json related project at Apache but a lot of projects
 rely on some specific implementions (jettison, jackson, others...).
 Proposing a default would be great. The other point is a set of Apache
 projects related to JavaEE (CXF, TomEE, Geronimo, Axis2...) will need an
 implementation. Having one built at Apache is a really nice to have.
 
 Initial Goals
 
 The initial goal of the Apache Fleece project is to get a JSR-353 compliant
 implementation
 
 Current Status
 
 Initial codebase was developped on github but designed to be integrated in
 Apache.
 
 Meritocracy
 
 Initial community will be mainly composed of already Apache committers so
 meritocracy is already something well known.
 
 Community
 
 Initial community will be composed of TomEE community for sure, hopefully
 CXF and potentially all JSon users of Apache.
 
 Initial committers
 
   - Romain Manni-Bucau (individual, ASF)
   - Jean-Louis Monteiro (individual, ASF)
   - Mark Struberg (individual, ASF member)
   - Gerhard Petracek (individual, ASF member)
   - David Blevins (individual, ASF member)
   - Sagara Gunathunga (ASF)
 
 Alignment
 
 Several Apache project will need a JSR-353 implementation. Having a project
 which can be shared is better than having a sub project of a particular
 project. Moreover this project makes sense alone since users can
 integrate it without any other dependencies and use it to read/generate
 Json in their project so it makes sense to create a dedicated project.
 
 Known Risks
 
 Main risk is to get a not so active project since the specification is not
 that big.
 
 Documentation
 
 There is no documentation to import today but it will be created using
 standard ASF tools (ASF CMS mainly).
 
 Initial Source
 
 Initial sources are on this git repository:
 https://github.com/rmannibucau/json-impl.git
 
 Source and IP Submission Plan
 
 Initial sources are under Apache license v2.
 
 Side note: it was really developed to be integrated in this project
 (without waiting it to be created).
 
 Required Resources
 
 Mailing Lists
 
   -
 
   - d...@fleece.incubator.apache.org - comm...@fleece.incubator.apache.org
   - priv...@fleece.incubator.apache.org
 
 Version Control
 
 It is proposed that the source code for the Apache Fleece project be hosted
 in the Apache Git repository, under the following directory:
 
   - git.apache.org/incubator-fleece.git
 
 Issue Tracking
 
 The following JIRA project would be required to track issues for the Apache
 Fleece project:
 
   - FLEECE
 
 Initial Committers
 
   - Romain Manni-Bucau
   - Jean-Louis Monteiro
   - Mark Struberg
   - Gerhard Petracek
   - David Blevins
 
 Sponsors
 
 Champion
 
   - Mark Struberg
 
 Nominated Mentors
 
   - Justin Mclean
   - Christian Grobmeier
   - Daniel Kulp
 
 Project Name
 
 Seems *Fleece* is the name which satisfies most of people but we can still
 ask for a new name if we feel it needed before being graduated.
 
 
 Romain Manni-Bucau
 Twitter: @rmannibucau
 Blog: 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

Re: [VOTE] Apache DeltaSpike 0.3-incubating

[David Blevins]

+1!


-David

On Aug 20, 2012, at 6:47 AM, Mark Struberg wrote:

 Hi Folks!
 
 The deltaspike-0.3-incubating vote has internally passed with lots of +1. 
 
 We have 2 IPMC +1 so far and like to ask for a tough review from fellow IPMCs.
 
 [+1] all fine, ship it 
 [+0] I don't care but smells fine 
 [-1] stop it, this stuff contains a blocker ${insertreason} 
 
 The VOTE is open for 72h.
 
 
 txs and LieGrue,
 strub
 
 
 
 - Forwarded Message -
 From: Mark Struberg strub...@yahoo.de
 To: deltaspike-...@incubator.apache.org 
 deltaspike-...@incubator.apache.org
 Cc: 
 Sent: Monday, August 20, 2012 3:43 PM
 Subject: Re: [VOTE] [RESULT] Apache DeltaSpike 0.3-incubating
 
 T ime to tally the vote.
 
 +1: Mark Struberg (IPMC), Shane Bryzak, Gerhard Petracek (IPMC),  Mehdi 
 Heidarzadeh (nonbinding), Lincoln Baxter, Romain Manni-Buccau, Thomas Herzog 
 (nonbinding), Cody Lerum, Arne Limburg, Charles Moulliard, Jason Porter, Ken 
 Finnigan, Christian Kaltepoth, Antoine Sabot-Durand
 
 no -1 and no 0.
 
 I'll forward the vote mail for a rewiew to general@incubator.
 
 LieGrue,
 strub
 
 
 - Original Message -
 From: Mark Struberg strub...@yahoo.de
 To: deltaspike deltaspike-...@incubator.apache.org
 Cc: 
 Sent: Wednesday, August 15, 2012 11:56 AM
 Subject: [VOTE] Apache DeltaSpike 0.3-incubating
 
 Hi!
 
 I like to call a VOTE on the Apache DeltaSpike 0.3-incubating release.
 
 
 The Maven staging repository:
 https://repository.apache.org/content/repositories/orgapachedeltaspike-010/
 
 The source release package:
 
 https://repository.apache.org/content/repositories/orgapachedeltaspike-010/org/apache/deltaspike/deltaspike-project/0.3-incubating/
 
 I've pushed the GIT release branch to my github account:
 
 https://github.com/struberg/incubator-deltaspike/tree/deltaspike-0.3-incubating
  
 
 (The branch will be pushed and merged to master after the VOTE passed.) 
 
 The TAG can be found here:
 
 https://github.com/struberg/incubator-deltaspike/tree/deltaspike-project-0.3-incubating
 
 Please note:
 This VOTE is majority approval with a minimum of three +1votes 
 of 
 PPMC members. 
 
 The VOTE is open for 72 hours. 
 
 
 [+1] all fine, ship it 
 
 [+0] I don't care but smells fine 
 
 [-1] stop it, this stuff contains a blocker ${insertreason} 
 
 
 
 LieGrue,
 strub
 
 
 
 -
 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] Release Apache DeltaSpike-0.2-incubating

[David Blevins]

+1 (binding)

-David

On Apr 18, 2012, at 10:09 AM, Mark Struberg wrote:

 Hi IPMC folks!
 
 I'd like to call the 2nd round (IPMC review/vote) for our 
 DeltaSpike-0.2-incubating release!
 
 See the attached thread for the release artifacts and the podling VOTE 
 results.
 
 We have 14 +1 inclucing 2 IPMC +1 so far: gpetracek, struberg.
 
 Here is a more readable form:
 http://markmail.org/thread/orik7hucchqfbhzr
 
 
 IPMC VOTE is open for 72h
 [+1] all fine, ship it
 
 [+0] puh, don't care
 [-1] nah, because ${problem}
 
 
 txs and LieGrue,
 strub
 
 
 
 - Forwarded Message -
 From: Mark Struberg strub...@yahoo.de
 To: deltaspike-...@incubator.apache.org 
 deltaspike-...@incubator.apache.org
 Cc: 
 Sent: Wednesday, April 18, 2012 7:02 PM
 Subject: Re: [VOTE] Release Apache DeltaSpike-0.2-incubating
 
 Hi folks!
 
 The internal DeltaSpike project VOTE passed with the following  
 
 binding +1:  Mark Struberg, Gerhard Petracek, John Ament, Cody Lerum, 
 Antoine 
 Sabot-Durand, Ken Finnigan, Jason Porter, Shane Bryzak, 
 
 
 non-binding +1: Łukasz Dywicki, Bruno Oliveira, Boleslaw Dawidowicz, Paul 
 Dijou, 
 Lincoln Baxter III, Mehdi Heidarzadeh
 
 +0: none
 -1: none
 
 
 I'll move this now over to the Incubator PMC to approve our release.
 
 
 txs 4 all who voted!
 LieGrue,
 strub
 
 
 
 PS: for the record again, here is my gpg key
 http://www.apache.org/dist/openwebbeans/KEYS
 Will update our section asap.
 
 
 
 - Original Message -
 From: Mark Struberg strub...@yahoo.de
 To: deltaspike deltaspike-...@incubator.apache.org
 Cc: 
 Sent: Sunday, April 15, 2012 10:30 PM
 Subject: [VOTE] Release Apache DeltaSpike-0.2-incubating
 
 Hi folks, I'd like to call a VOTE on releasing Apache DeltaSpike 
 0.2-incubating. The Maven staging repository:
 https://repository.apache.org/content/repositories/orgapachedeltaspike-051/ 
 
 Source release: 
 
 https://repository.apache.org/content/repositories/orgapachedeltaspike-051/org/apache/deltaspike/deltaspike-project/0.2-incubating/deltaspike-project-0.2-incubating-source-release.zip
 
 Here are the md5 and sha1:
 
 https://repository.apache.org/content/repositories/orgapachedeltaspike-051/org/apache/deltaspike/deltaspike-project/0.2-incubating/
 
 
 I've pushed the GIT release branch to my github account:
 
 https://github.com/struberg/incubator-deltaspike/tree/deltaspike-0.2-incubating
 (The branch will be pushed and merged to master after the VOTE passed.)
 
 The TAG can be found here:
 
 https://github.com/struberg/incubator-deltaspike/zipball/deltaspike-project-0.2-incubating
 
 Please note:
 This vote is majority approval with a minimum of three +1 votes 
 of 
 PPMC members.
 This vote is open for 72 hours.
 
 [+1] all fine, ship it
 [+0] I don't care but smells fine
 [-1] stop it, this stuff contains a blocker ${insertname}
 
 
 
 LieGrue,
 strub
 
 
 
 -
 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][IPMC] Graduate RAT as Apache Creadur Project

[David Blevins]

+1 (binding)


On Mar 11, 2012, at 2:42 PM, Robert Burrell Donkin wrote:

 As recommended[1]:
 
 * the Rat community has indicated that its readiness[2] to graduate as the 
 Apache Creadur Project
 * the proposed charter has been reviewed[3]
 
 The penultimate stage is this VOTE by the incubator community. The VOTE is 
 open to all but only IPMC votes are binding.
 
 I will tally the results no earlier than noon UTC on Thursday, March 22, 
 2012[4].
 
 Robert
 
 [1] http://incubator.apache.org/guides/graduation.html#toplevel
 [2] 
 http://mail-archives.apache.org/mod_mbox/incubator-general/201203.mbox/%3C4F53968D.7070908%40apache.org%3E
 [3] 
 http://mail-archives.apache.org/mod_mbox/incubator-general/201203.mbox/%3C4F53B9FB.4030404%40apache.org%3E
 [4] 
 http://www.worldtimeserver.com/convert_time_in_UTC.aspx?y=2012mo=3d=22h=12mn=0
 
 -8---
 [ ] +1 Recommend The Apache Creadur Proposal To The Board (below)
 [ ] +0
 [ ] -0
 [ ] -1 Do not graduate Rat podling
 --
 
 -8--
 
 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 comprehension and
 auditing of software distributions 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 Creadur Project,
 be and hereby is established pursuant to Bylaws of the
 Foundation; and be it further
 
 RESOLVED, that the Apache Creadur Project be and hereby is
 responsible for the creation and maintenance of open-source
 software related to the comprehension and auditing of software
 distributions; and be it further
 
 RESOLVED, that the office of Vice President, Apache Creadur 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 Creadur Project, and to have primary responsibility
 for management of the projects within the scope of
 responsibility of the Apache Creadur 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 Creadur Project:
 
  * Stefan Bodewig bode...@apache.org
  * Brian E Fox bri...@apache.org
  * David Crossley cross...@apache.org
  * David Blevins dblev...@apache.org
  * Dennis Lundberg denn...@apache.org
  * Gavin McDonald gmcdon...@apache.org
  * Jochen Wiedmann joc...@apache.org
  * Niall Pemberton nia...@apache.org
  * Robert Burrell Donkin rdon...@apache.org
  * Ross Duncan Gardler rgard...@apache.org
  * Sebastian Bazley s...@apache.org
 
 NOW, THEREFORE, BE IT FURTHER RESOLVED, that Robert Burrell
 Donkin be appointed to the office of Vice President, Apache
 Creadur, 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 Creadur 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 Creadur Project; and be it further
 
 RESOLVED, that the Apache Creadur Project be and hereby
 is tasked with the migration and rationalization of the Apache
 Incubator RAT podling; and be it further
 
 RESOLVED, that all responsibilities pertaining to the Apache
 Incubator RAT podling encumbered upon the Apache Incubator
 Project are hereafter discharged.


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] DeltaSpike to join the Incubator

[David Blevins]

 (Red Hat)
* Pete Muir (Red Hat)
* George Gastaldi (Independent contributor)
* John Ament (Independent contributor)
* Cody Lerum (Independent contributor)
* Antoine 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

Re: [VOTE] Kalumet to join Incubator

[David Blevins]

Looks very interesting!

 +1  (non-binding)


-David


On Sep 13, 2011, at 12:18 AM, Olivier Lamy wrote:

 Hello Folks,
 
 Please vote on the acceptance of Kalumet into the Apache incubator.
 
 The proposal is available at: http://wiki.apache.org/incubator/KalumetProposal
 (for your convenience, a snapshot is also copied below)
 
 The vote options (please cast your vote) :
 
 [ ] +1 Accept Kalumet for incubation
 [ ] +0 Don't care
 [ ] -1 Reject for the following reason:
 
 The vote is open for 72 hours.
 
 Here my (binding) +1 .
 
 Thanks,
 -- 
 Olivier Lamy
 Talend : http://talend.com
 http://twitter.com/olamy | http://linkedin.com/in/olamy
 
 
 = Kalumet - Complete Environment Deployer Toolbox =
 
 == Abstract ==
 
 Kalumet a complete environment manager and deployer including J2EE
 environments (application servers, applications, etc), softwares, and
 resources.
 It's a perfect complement to continuous integration (managed by maven
 and continuum or jenkins for instance) by adding continuous
 deployment.
 The whole factory chain is cover and the software administrator
 managed all environments in secure and safe way, whatever the
 underlying application servers (Apache Geronimo, Apache Tomcat, Apache
 TomEE, RedHat JBoss, Oracle Weblogic or IBM Websphere) or softwares
 (printout system, Apache HTTPd, operating systems, etc) are.
 
 Kalumet provides two kind of components :
 
 * Apache Kalumet agent are installed locally on the target server box.
 
 * Apache Kalumet console controls and manages the agents, allowing the
 software administrator to update all environments from a central
 multi-user web tool.
 
 == Background ==
 
 Currently, Apache Kalumet is named BuildProcess AutoDeploy
 (http://buildprocess.sourceforge.net). The development has begun 4
 years ago and several release have already been provided.
 
 == Rationale ==
 
 The software environments administration is heavy cost task with a
 high level of human actions, especially when mixing J2EE environments,
 different operating systems, softwares, etc It suffers :
 
 * a different set of scripts or actions/procedures depending of the
 application server used (Geronimo, Tomcat, JBoss, Weblogic, Websphere,
 ...) or other middlewares (portals or ESB like ServiceMix, HTTP
 servers like Apache HTTPd, etc);
 
 * a high level of risk due to human actions (for example, an
 administrator can forget to deploy a JDBC DataSource, or forget to
 change an application configuration file);
 
 * migrate an application from an environment to another one request
 boring actions (for example, migration applications and all linked
 resources from a testing environment to a production one, this action
 is named promote);
 
 * the upgrade process can be long (depending of the number of
 applications and complexity);
 
 * most of resources are stored on the application server box, not in a
 central repository.
 
 Apache Kalumet secures the environment deployment and covers the whole
 environment scope including J2EE parts (EAR/WAR archives with
 classloader policy, JDBC DataSources, JMS Connection Factories, JMS
 Queues/Topics, etc) and resources (operating systems, softwares, etc)
 in a unique way. It's heavily expendable, that means that you can
 create new plugins for dedicated resources.
 
 == Initial Goals ==
 
 When we have begun AutoDeploy, the first goal was to provide several
 J2EE application servers JMX plugins. But quickly, we have seen that
 multi-application servers support was only a part of the software
 administration needs.
 
 That's why we have extended AutoDeploy to provide agents and a central
 console hosting all environments knowledges (artifact versions,
 resources, etc). Using the console, several administrators can use a
 central tool to manage all environments in a collaborative, unique and
 secure way.
 
 The target is now to provide a complete tool to fully administrate a
 data center servers, softwares and middlewares.
 
 = Current Status =
 
 Currently, BuildProcess AutoDeploy provides two branches :
 
 * the 0.5 branch (with the 0.5.6 latest release) is the current stable
 branch. This branch is built every night using Apache Continuum
 (http://continuum.nanthrax.net).
 
 * the 0.6 branch is in progress and it's the target one to become Apache 
 Kalumet
 
 == Community ==
 
 Currently, AutoDeploy community contains two comitters, 5 contributors
 and around 50 users.
 BuildProcess AutoDeploy is used in production and test in several companies :
 
 * Fimasys France (http://www.fimasys.com)
 
 * AMP-AXA Australia (https://www.amp.com.au/wps/portal/au)
 
 * Vodacom South Africa (http://www.vodacom.com)
 
 * Mayo Clinic USA (http://www.mayoclinic.com)
 
 * NSW Attorney General Australia (http://www.lawlink.nsw.gov.au)
 
 == Core Developers ==
 
 The core developers for AutoDeploy/Apache Kalumet project are :
 
 * Jean-Baptiste Onofré (founder in 2004).
 
 * Mike Duffy, WebSphere Consultant, contributes since 2005.
 
 == Open Source ==
 
 

Re: [vote] (repost) Propose OpenEJB for graduation to a TLP

[David Blevins]

On May 4, 2007, at 6:11 AM, Eddie O'Neil wrote:


 +1 -- good luck out in the World!


The project started Dec 1999, but I know what you mean :)  Thanks for  
the good wishes, we're pretty excited too!


-David



Eddie

On 5/4/07, Niclas Hedhman [EMAIL PROTECTED] wrote:

+1

Cheers
Niclas

On 5/3/07, Brett Porter [EMAIL PROTECTED] wrote:
 After the previous discussion, the proposal has been amended to
 include the new wording. We will restart the vote.

 Please cast your votes on whether to recommend this proposal.

 Thanks,
 Brett
 (OpenEJB Mentor)

Establish Apache OpenEJB 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

enterprise application containers and object distribution
services based on, but not limited to the Enterprise  
JavaBeans

Specification.

NOW, THEREFORE, BE IT RESOLVED, that a Project Management
Committee (PMC), to be known as the The Apache OpenEJB  
Project,

be and hereby is established pursuant to Bylaws of the
Foundation; and be it further

RESOLVED, that The Apache OpenEJB Project be and hereby is
responsible for enterprise application containers and object
distribution services based on, but not limited to the  
Enterprise

JavaBeans Specification; and be it further

RESOLVED, that the office of Vice President, Apache OpenEJB
Project 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 OpenEJB Project, and to have primary  
responsibility
for management of the projects within the scope of  
responsibility

of The Apache OpenEJB 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 OpenEJB Project:

  * David Blevins   ([EMAIL PROTECTED])
  * Alan Cabrera([EMAIL PROTECTED])
  * David Jencks([EMAIL PROTECTED])
  * Jacek Laskowski ([EMAIL PROTECTED])
  * Brett Porter([EMAIL PROTECTED])
  * Dain Sundstrom  ([EMAIL PROTECTED])

NOW, THEREFORE, BE IT FURTHER RESOLVED, that David  
Blevins be

appointed to the office of Vice President, Apache OpenEJB
Project, 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 OpenEJB Project be and  
hereby
is tasked with the migration and rationalization of the  
Apache

Incubator OpenEJB podling; and be it further

RESOLVED, that all responsibility pertaining to the Apache
Incubator OpenEJB podling encumbered upon the Apache  
Incubator

PMC are hereafter discharged.

  
-

 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [vote] (repost) Propose OpenEJB for graduation to a TLP

[David Blevins]

On May 3, 2007, at 3:16 AM, Noel J. Bergman wrote:


+1

However, IFF (if and only if, for those not posessing a math or  
logic
background), it isn't too much trouble, could you recast it in the  
form of

the revised template?

Mind you, that's really an issue for the Board, so it doesn't  
require a
revote here if the non-template text remains the same, but I just  
spent time
with Greg and Ken (separately) working on the Board resolution  
templates.




:)   Got your note on that and updated the text yesterday.  I did an  
eye-ball diff, though, so it's very possible I missed something.   
Here's the delta:


  http://svn.apache.org/viewvc?view=revrevision=534676

-David


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [vote] Propose OpenEJB for graduation to a TLP

[David Blevins]

On May 2, 2007, at 3:23 AM, Noel J. Bergman wrote:


David Blevins wrote:


Here's the revised language:


   RESOLVED, that The Apache OpenEJB Project be and hereby is
   responsible for the creation and maintenance of a software
   project related to enterprise application containers and
   object distribution services [based on, but not limited to
   the Enterprice Java Beans Specification]; and be it further

Does that work for you?  It feels more descriptive without being  
limiting.


Works for me.

-David


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [vote] Propose OpenEJB for graduation to a TLP

[David Blevins]

Noel, we definitely understand we don't have an exclusive lock on  
any ASF land; we understand perfectly that's not how the ASF works :)


-David

On May 1, 2007, at 12:47 AM, Noel J. Bergman wrote:


David Blevins wrote:


Noel J. Bergman wrote:

David Blevins wrote:

We could use Scalable, transactional, and multi-user
secure architecture for the development and deployment
of component-based business applications

How would that differ from River or WS (various WS-* specs cover
transactions and security)?

They don't differ really as EJBs are web services too.


Perhaps this is devolving into a bikeshed, but I am thinking that the
description ought to either distinguish OpenEJB from any of several  
other

such projects at the ASF, or not sound like it has an exclusive on the
territory.  At this point, I've lost track of what text you're  
proposing in
context (context of these text segments being the key point), so  
just give

this some thought.


The definition of ejb spells out Scalable, transactional, and
multi-user secure which is summed up by the word 'enterprise'.
So maybe something like creation and maintenance of enterprise
application containers and object distribution.  Maybe expand
that last part to object distribution servers, kind of awkward
but uses Container and Server which are the primary two words
we use to describe our architecture

Those are words used throughout the JEE model: Web Container, EJB
container, Portlet Container (superclass of Servlet Container),
Client Container, Applet Container, ... JEE is all about container
managed components.

None of those you listed are transactional except EJB.


I was referring to the words container and server being your  
primary two
words, hence my enumeration of the various containers (yes, not  
all are on
the server-side).  The transaction managing container is probably  
closer to

one of your distinguishing characteristics.


the security in Web Containers (superclass of Portlet, not the other
way around) is very focused on transports and has no other mechanisms
for securing application logic.


I'd view that as wrong on all counts, but let's not further hijack the
thread.  Catch me elsewhere if you want to discuss it.


We've always supported plugging in containers that support other
models, so the answer is anything capable of being invoked.  With
the latest EJB spec, that's pretty much a requirement as any Plain
Old Java Object can be deployed into an EJB container.  You no longer
have to make the distinction in your application code.


So there is really nothing to distinguish between OpenEJB and  
Geronimo, for
example, in so far as the description of the scope of the project.   
Again,
not necessarily an issue, except for any implication in the  
phrasing that

the project has an exclusive on the listed concepts.


if we wanted to just say The ASF definition of OpenEJB is EJB
and let it be that, I personally wouldn't be inconvenienced as
I am one of the few people who get to decide what EJB means.  Even
though Apache gets a seat on expert groups, they are still closed
groups.


A separate matter that needs to be addressed by the entire Java  
community
with the JCP.  JSRs really need to become more open uniformly, not  
just the

few run by more enlightened spec leads.


there is a problem space that EJB aims to solve and much of what
OpenEJB offers in that problem space will never be part of the
EJB spec or is part of another spec (like, EARs and Client
Containers), so simply calling it EJB doesn't seem like it covers
the whole project.


Fair enough.  There is a lot that's under the JEE umbrella, not  
under the

piece labeled EJB.  And a supporting argument that there are many (and
sometimes necessary) extensions to EJB in vendor EJB products such as
WebSphere.  Again, I would ontologically expect to find some in  
Geronimo

more than in OpenEJB, but we don't parcel out functional areas for ASF
projects.  Just make sure that it doesn't sound like you've claimed  
one.



This discussion has already resulted in a much better description
of the EJB problem space, IMHO.


:-)

By the way, anyone here at ApacheCon?

--- Noel



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [vote] Propose OpenEJB for graduation to a TLP

[David Blevins]

On May 1, 2007, at 1:27 PM, Noel J. Bergman wrote:


we definitely understand we don't have an exclusive lock on
any ASF land; we understand perfectly that's not how the ASF works :)


:-)

As I allowed earlier, the discourse devolved a bit into a  
bikeshed.  :-)  I

look forward to the revised language, and OpenEJB's graduation.


:)

Here's the revised language:

 http://svn.apache.org/repos/asf/incubator/openejb/trunk/graduation- 
resolution.txt


Contains some good verbiage from Robert enterprise application  
containers and a more specific description of the nature of our  
server half, distributed object services.


I think it fits us like a glove (way better than what we had) and  
we've already gotten some good feedback on it at the openejb dev  
list, but if you see some room for improvement we're happy to  
incorporate it.


Thanks!

-David


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [vote] Propose OpenEJB for graduation to a TLP

[David Blevins]

Noel J. Bergman wrote:

David Blevins wrote:

We could use Scalable, transactional, and multi-user
secure architecture for the development and deployment
of component-based business applications


How would that differ from River or WS (various WS-* specs cover
transactions and security)?


They don't differ really as EJBs are web services too.

Noel J. Bergman wrote:

David Blevins wrote:

The definition of ejb spells out Scalable, transactional, and
multi-user secure which is summed up by the word 'enterprise'.
So maybe something like creation and maintenance of enterprise
application containers and object distribution.  Maybe expand
that last part to object distribution servers, kind of awkward
but uses Container and Server which are  the primary two words
we use to describe our architecture


Those are words used throughout the JEE model: Web Container, EJB  
container,

Portlet Container (superclass of Servlet Container), Client Container,
Applet Container, ... JEE is all about container managed components.


Somewhat true.  None of those you listed are transactional except  
EJB.  Applets (not actually part of JEE) and Client Containers are  
not multi-user secure or scalable.  And the security in Web  
Containers (superclass of Portlet, not the other way around) is very  
focused on transports and has no other mechanisms for securing  
application logic.


Noel J. Bergman wrote:

David Blevins wrote:

Ok, going with object distribution services as I think that
describes a less singular approach to supporting distributed
objects.  At current date we support invocations over our custom
protocol, CORBA, HTTP, JMS, JAX-RPC, JAX-WS, even telnet.  We
have a container/server contract and a server implementation
that allows for numberous ServerService (i.e. protocols) to be
plugged in and standardly configured in an xinet.d style config.


Invocations of what?  What types of components are supported by the
container?  The EJB contract, surely.  Other components too, just  
different

means to invoke EJB components?


We've always supported plugging in containers that support other  
models, so the answer is anything capable of being invoked.  With the  
latest EJB spec, that's pretty much a requirement as any Plain Old  
Java Object can be deployed into an EJB container.  You no longer  
have to make the distinction in your application code.


Noel J. Bergman wrote:

David Blevins wrote:

Generally, I think it's good to use words that describe EJB then the
words Enterprise JavaBeans specifically.  Primarily because I think
it's good to be able to innovate in the space and not limit ourselves
to the ideas approved by the EJB JSR Expert Group.


Isn't the point of OpenEJB to implement the EJB Spec?  I understand  
that
it's very much in the nature of the project to go beyond EJB and  
test the
limits of what it means to write enterprise applications in any way  
we can
possibly imagine, but that feels a bit fuzzy.  Perhaps it doesn't  
matter,

but ... shrug


I know it seems like half a dozen of one and six of the other, but  
there is an important difference community wise.  The OpenEJB  
community does not get to decide what goes into the EJB spec.  I  
personally have had the privilege to participate in the EJB expert  
group.  So if we wanted to just say The ASF definition of OpenEJB is  
'EJB' and let it be that, I personally wouldn't be inconvenienced as  
I am one of the few people who get to decide what EJB means.  Even  
though Apache gets a seat on expert groups, they are still closed  
groups.  Also, there is a problem space that EJB aims to solve and  
much of what OpenEJB offers in that problem space will never be part  
of the EJB spec or is part of another spec (like, EARs and Client  
Containers), so simply calling it EJB doesn't seem like it covers  
the whole project.


Does any of that make any sense?  I do wonder if I'm far too close to  
the subject, so outside feedback is definitely helpful.  This  
discussion has already resulted in a much better description of the  
EJB problem space, IMHO.


-David




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [vote] Propose OpenEJB for graduation to a TLP

[David Blevins]

On Apr 30, 2007, at 4:57 PM, Sanjiva Weerawarana wrote:


David Blevins wrote:

Couldn't that be in EJB and related technologies ??
Certainly implementing the EJB spec is a constant for the project,  
so that description would be adequate.  It does give me an ick  
feeling though as it's very much in the nature of the project to  
go beyond EJB and test the limits of what it means to write  
enterprise applications in any way we can possibly imagine.  It  
just seems summing that up as and related technologies just  
doesn't capture that spirit.  It'd definitely be our preference to  
be able to portray ourselves as more than just EJB.


+1 for keeping that room, but in that case maybe come up with a  
better name than OpenEJB? The name is clearly designed to imply  
certain functionality.


I don't think calling it OpenEJB is such a big issue.  The project is  
seven years old so a lot of us are really tied to the name and I  
think it does allow is the advantage to stretch the world of EJB a  
bit and still have people understand more or less what we're about.   
We hope though as they learn more about us they appreciate/love that  
we do things other EJB implementations don't/won't do and we aren't  
afraid to go outside the spec to do it.  We hope that it results in  
people thinking hey, cool, that's how all ejb containers should  
work or this should be part of the spec.


-David



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [vote] Propose OpenEJB for graduation to a TLP

[David Blevins]

On Apr 27, 2007, at 3:19 PM, David Blevins wrote:



On Apr 27, 2007, at 12:40 PM, robert burrell donkin wrote:


On 4/25/07, David Blevins [EMAIL PROTECTED] wrote:


On Apr 24, 2007, at 12:46 PM, Brett Porter wrote:

 On 24/04/07, Noel J. Bergman [EMAIL PROTECTED] wrote:

  the creation and maintenance of open-source software related to
  enterprise application and remoting services, for  
distribution at

  no charge to the public.

 A bit generic for a project that is intended to managing an
 implementation
 of a well-defined specification?


 I think it's accurate - it doesn't implement the entire EJB spec
 (using other components such as OpenJPA to do so), and it would  
be in

 scope to do additional, non-EJB things that make it better at the
 purpose stated here.

We could use Scalable, transactional, and multi-user secure
architecture for the development and deployment of component-based
business applications, but that'd be plagiarism as that's a
minimally paraphrased version the definition of EJB in the JSR.

Generally, I think it's good to use words that describe EJB then the
words Enterprise JavaBeans specifically.  Primarily because I think
it's good to be able to innovate in the space and not limit  
ourselves

to the ideas approved by the EJB JSR Expert Group.


i see your point but the original language isn't great: it's all a
little wholly. for example, remoting services could be read as
service provision.

perhaps something more like: creation and maintenance of
transactional application containers capable of connection by remote
clients...?


That could work.  The definition of ejb spells out Scalable,  
transactional, and multi-user secure which is summed up by the  
word 'enterprise'.  So maybe something like creation and  
maintenance of enterprise application containers and object  
distribution.  Maybe expand that last part to object distribution  
servers, kind of awkward but uses Container and Server which are  
the primary two words we use to describe our architecture (i.e. the  
openejb container/server contract).  Or one last mutation could be  
to use services instead of server which might be less awkward,  
giving us object distribution services.


Preferences, thoughts?


Ok, going with object distribution services as I think that  
describes a less singular approach to supporting distributed  
objects.  At current date we support invocations over our custom  
protocol, CORBA, HTTP, JMS, JAX-RPC, JAX-WS, even telnet.  We have a  
container/server contract and a server implementation that allows for  
numberous ServerService (i.e. protocols) to be plugged in and  
standardly configured in an xinet.d style config.  Adding a new  
protocol is literally an act of dropping in a jar and rebooting.  And  
I'm not sure what is meant by service provisioning, but we do have  
the capability for you to deploy a client app in advance and then  
walk up to the server later with an empty client and sort of say I  
want to be client 'foo' and your empty client will download all the  
previously deployed environment for client foo (i.e. security info,  
naming entries, ejb references, jms queue/topic references, etc.).


-David






-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [vote] Propose OpenEJB for graduation to a TLP

[David Blevins]

On Apr 27, 2007, at 12:40 PM, robert burrell donkin wrote:


On 4/25/07, David Blevins [EMAIL PROTECTED] wrote:


On Apr 24, 2007, at 12:46 PM, Brett Porter wrote:

 On 24/04/07, Noel J. Bergman [EMAIL PROTECTED] wrote:

  the creation and maintenance of open-source software related to
  enterprise application and remoting services, for  
distribution at

  no charge to the public.

 A bit generic for a project that is intended to managing an
 implementation
 of a well-defined specification?


 I think it's accurate - it doesn't implement the entire EJB spec
 (using other components such as OpenJPA to do so), and it would  
be in

 scope to do additional, non-EJB things that make it better at the
 purpose stated here.

We could use Scalable, transactional, and multi-user secure
architecture for the development and deployment of component-based
business applications, but that'd be plagiarism as that's a
minimally paraphrased version the definition of EJB in the JSR.

Generally, I think it's good to use words that describe EJB then the
words Enterprise JavaBeans specifically.  Primarily because I think
it's good to be able to innovate in the space and not limit ourselves
to the ideas approved by the EJB JSR Expert Group.


i see your point but the original language isn't great: it's all a
little wholly. for example, remoting services could be read as
service provision.

perhaps something more like: creation and maintenance of
transactional application containers capable of connection by remote
clients...?


That could work.  The definition of ejb spells out Scalable,  
transactional, and multi-user secure which is summed up by the word  
'enterprise'.  So maybe something like creation and maintenance of  
enterprise application containers and object distribution.  Maybe  
expand that last part to object distribution servers, kind of  
awkward but uses Container and Server which are the primary two words  
we use to describe our architecture (i.e. the openejb container/ 
server contract).  Or one last mutation could be to use services  
instead of server which might be less awkward, giving us object  
distribution services.


Preferences, thoughts?

-David


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [vote] Propose OpenEJB for graduation to a TLP

[David Blevins]

Haven't seen any more discussion, so just following up.  Noel, were  
your questions answered to your liking?  Niclas?


-David

On Apr 24, 2007, at 10:09 AM, Noel J. Bergman wrote:


Brett,

What is the diversity of the Committer list and the PMC?


the creation and maintenance of open-source software related to
enterprise application and remoting services, for distribution at
no charge to the public.


A bit generic for a project that is intended to managing an  
implementation

of a well-defined specification?

--- Noel



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [vote] Propose OpenEJB for graduation to a TLP

[David Blevins]

On Apr 24, 2007, at 12:46 PM, Brett Porter wrote:


On 24/04/07, Noel J. Bergman [EMAIL PROTECTED] wrote:


 the creation and maintenance of open-source software related to
 enterprise application and remoting services, for distribution at
 no charge to the public.

A bit generic for a project that is intended to managing an  
implementation

of a well-defined specification?



I think it's accurate - it doesn't implement the entire EJB spec
(using other components such as OpenJPA to do so), and it would be in
scope to do additional, non-EJB things that make it better at the
purpose stated here.


We could use Scalable, transactional, and multi-user secure  
architecture for the development and deployment of component-based  
business applications, but that'd be plagiarism as that's a  
minimally paraphrased version the definition of EJB in the JSR.


Generally, I think it's good to use words that describe EJB then the  
words Enterprise JavaBeans specifically.  Primarily because I think  
it's good to be able to innovate in the space and not limit ourselves  
to the ideas approved by the EJB JSR Expert Group.


-David




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [vote] Propose OpenEJB for graduation to a TLP

[David Blevins]

On Apr 24, 2007, at 7:41 PM, Niclas Hedhman wrote:


On Wednesday 25 April 2007 08:31, David Blevins wrote:


Generally, I think it's good to use words that describe EJB then the
words Enterprise JavaBeans specifically.  Primarily because I think
it's good to be able to innovate in the space and not limit ourselves
to the ideas approved by the EJB JSR Expert Group.


Couldn't that be in EJB and related technologies ??


Certainly implementing the EJB spec is a constant for the project, so  
that description would be adequate.  It does give me an ick feeling  
though as it's very much in the nature of the project to go beyond  
EJB and test the limits of what it means to write enterprise  
applications in any way we can possibly imagine.  It just seems  
summing that up as and related technologies just doesn't capture  
that spirit.  It'd definitely be our preference to be able to portray  
ourselves as more than just EJB.



-David






-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [vote] ActiveMQ Graduation

[David Blevins]

+1

-David

On Jan 9, 2007, at 8:46 AM, Brian McCallister wrote:


On Jan 9, 2007, at 8:21 AM, Henri Yandell wrote:


On 1/9/07, Justin Erenkrantz [EMAIL PROTECTED] wrote:


1) The Board meeting is on the 17th, so this will likely be too late
to add to this month's agenda.  (You can see if we're willing to  
hold

a spot open for ActiveMQ, but it's iffy if you were to submit it on
Tuesday.)


No worries, we can wait until the following if need be, there is no  
race I know :-) If it gets in, great, if not, so be it.


2) The resolution has the dreaded PMC virus.  Where did you get  
this
template from?  It's bogus.  Please fix.  Harmony's template is  
here:


http://www.apache.org/foundation/records/minutes/2006/ 
board_minutes_2006_10_25.txt


or:

https://svn.apache.org/repos/private/committers/board/templates/ 
podling-tlp-resolution.txt


Please consider the proposed resolution changed to (using the  
podling-tlp-resolution):


Establish the Apache ActiveMQ 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
   implementing a distributed messaging system, 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 ActiveMQ Project,
   be and hereby is established pursuant to Bylaws of the
   Foundation; and be it further

   RESOLVED, that the Apache ActiveMQ Project be and hereby is
   responsible for the creation and maintenance of open-source
   software and documentation for a distributed messaging system,
   based on software licensed to the Foundation; and be it
   further

   RESOLVED, that the office of Vice President, ActiveMQ 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 ActiveMQ Project, and to have primary responsibility for
   management of the projects within the scope of responsibility
   of the Apache ActiveMQ 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 ActiveMQ Project:

   * Alan Cabrera [EMAIL PROTECTED]
   * Hiram Chirino [EMAIL PROTECTED]
   * Rob Davies [EMAIL PROTECTED]
   * Matt Hogstrom [EMAIL PROTECTED]
   * David Jencks [EMAIL PROTECTED]
   * Brian McCallister [EMAIL PROTECTED]
   * Aaron Mulder [EMAIL PROTECTED]
   * Guillaume Nodet [EMAIL PROTECTED]
   * John Sisson [EMAIL PROTECTED]
   * Bruce Snyder [EMAIL PROTECTED]
   * James Strachan [EMAIL PROTECTED]
   * Dain Sundstrom [EMAIL PROTECTED]

   NOW, THEREFORE, BE IT FURTHER RESOLVED, that Brian McCallister
   be appointed to the office of Vice President, ActiveMQ, 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 ActiveMQ Project be and  
hereby

   is tasked with the creation of a set of bylaws intended to
   encourage open development and increased participation in the
   ActiveMQ Project; and be it further

   RESOLVED, that the initial Apache ActiveMQ Project be and  
hereby

   is tasked with the migration and rationalization of the Apache
   Incubator ActiveMQ podling; and be it further

   RESOLVED, that all responsibility pertaining to the Apache
   Incubator ActiveMQ podling encumbered upon the Apache Incubator
   PMC are hereafter discharged.




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Setting up a Maven 2 repo Was: Maven 2 repo for incubating project releases?

[David Blevins]

On Aug 18, 2006, at 8:49 AM, Jason van Zyl wrote:



On 18 Aug 06, at 11:30 AM 18 Aug 06, Dan Diephouse wrote:

Yeah, I find this a bit confusing too. The ibiblio repository  
distribution policy is unrelated to Apache's. No one is making any  
claims on ibiblio about  the licensing (other than its freely  
distributable)/community/etc - I mean, come on, there are  
sourceforge binaries on there! :-)


Also, Guillaume makes a good point, anybody create upload requests  
for ibiblio. Why couldn't I go make an upload request for any of  
the incubating projects? You don't have to be a project  
coordinator to get jars uploaded. It only needs to be a freely  
distributable binary.


I'm +1 to creating the repositories and its a very necessary first  
step, but I think things should go further.




I think in terms of physical separation on Apache infrastructure  
this is a good thing so that we could run the repository manager on  
that separate repository to get stats on incubator artifact  
activity. Project using Maven in the incubator can specify a set of  
repositories to use so it wouldn't be onerous to have artifacts be  
pulled from the incubator repository. But I honestly don't think  
there is much downside in syncing to Ibiblio but I suppose that is  
a decision for the Incubator PMC to decide. That is probably the  
thing to clear up.


Those are some good points.

Thinking of the projects that I have in incubation at the current  
time, I get a little sinking feeling in my stomach at the thought  
they could be out of wide-spread distribution for a year.


-David



- Dan

Guillaume Nodet wrote:
What is the real purpose of such a repository if it is not synced  
to ibiblio ?

What if a user of an incubating project create an upload request ?
There's no reason why Apache internal policies would affect such  
a request.

AFAIK, Ibiblio repository is not owned by the ASF ...

Jason van Zyl wrote:

+1

On 14 Aug 06, at 5:03 PM 14 Aug 06, Henri Yandell wrote:


On 8/7/06, Henri Yandell [EMAIL PROTECTED] wrote:


 people.apache.org/repo/m1-incubating-repository
 people.apache.org/repo/m2-incubating-repository

Noel, shall I go ahead and create the above? They get my +1  
from a

repository@ point of view.


Pinging on this to make sure the Incubator is happy with the idea
before I set it up.

Hen

-- 
---

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Jason van Zyl
[EMAIL PROTECTED]




--- 
--

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





 
-

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com
http://netzooid.com/blog


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Jason van Zyl
[EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [rant] seperate policy change from proposal discussion

[David Blevins]

A big +1.  And I also really like the idea that the proposals contain  
the version number they were written against.


-David

On Aug 8, 2006, at 6:34 AM, J Aaron Farr wrote:


On 8/8/06, Leo Simons [EMAIL PROTECTED] wrote:


Perhaps we should try and seperate this somewhat more rigidly. Eg we
could have a released version of all the things we want a  
project to

do and/or comply with (this is our website) and we could have an
in progress version of the same thing (this is what changes more
rapidly). And *new proposals should be evaluated against the  
released

one*.


+1

This is one of my biggest concerns -- the rapidly changing  
requirements.


This is easy enough to do as well.  The released version (with a
release number) is on the public website and the in progress version
could be on the wiki.  Proposals should include the version number
they were written against.

--
 jaaron

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (INCUBATOR-24) Setup OpenEJB mailing lists

[David Blevins (JIRA)]

[ 
http://issues.apache.org/jira/browse/INCUBATOR-24?page=comments#action_12421489 
] 

David Blevins commented on INCUBATOR-24:


don't have the perms to reopen it

 Setup OpenEJB mailing lists
 ---

 Key: INCUBATOR-24
 URL: http://issues.apache.org/jira/browse/INCUBATOR-24
 Project: Incubator
  Issue Type: Task
Reporter: David Blevins

 * openejb-dev@incubator.apache.org 
 * [EMAIL PROTECTED] 
 * [EMAIL PROTECTED] 
 http://wiki.apache.org/incubator/OpenEjbProposal

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Mentors - the more, the merrier? [WAS Re: [VOTE] Accept Heraldry into the Incubator]

[David Blevins]

On Jul 13, 2006, at 10:49 PM, Ted Leung wrote:



On Jul 13, 2006, at 7:16 PM, David Blevins wrote:


In the ASF we do have PMC Chairs, period.
Now let's say, someone wins this debate on wether or not  having a  
PMC Chair from inside or outside the project is more or less  
likely to result in dependence.  I'm not of the opinion that we  
shouldn't be removing temptations or confusing dualities of the  
ASF while projects are in the incubator only for these projects to  
struggle with them after graduation.


Actually on the projects that I have previously mentored, we had  
PPMCs.   We did not have a PMC chair until the project graduated.
So we are discussing whether having a chair for the PPMC is a good  
idea or not, and and my thinking on this was it would be good  
practice.But now I am starting to think that maybe the good  
practice that is needed is how to work without a chair or official  
leader.   If you put that person in from the start, then there is  
never an opportunity to learn that you can function without that  
person.


Ok, I see.  Hmm... going to have to think about that.

I have the gut feeling there is something we can do to marry these  
concerns, as my primary concern is how the incubation ends.  I.e. I  
think there should be an opportunity before incubation ends to learn  
to function *with* that person and someone in the project to learn to  
*be* that person.


-David


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Mentors - the more, the merrier? [WAS Re: [VOTE] Accept Heraldry into the Incubator]

[David Blevins]

Sorry, I can't resist...

On Jul 14, 2006, at 1:14 PM, Noel J. Bergman wrote:

ASF Members are automatically
eligible for PMC membership; non-Members may be elected at the  
discretion of

the Incubator PMC.


with-big-grin
This is some of that non-hierarchical, peer-based stuff you were  
talking about, right? :)

/with-big-grin


-David

/me owes Noel a non-alcoholic beer


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Mentors - the more, the merrier? [WAS Re: [VOTE] Accept Heraldry into the Incubator]

[David Blevins]

On Jul 13, 2006, at 5:49 PM, Ted Leung wrote:


On Jul 13, 2006, at 5:41 PM, Noel J. Bergman wrote:


How hard is it to understand that the PMC Chair has no role (slight
hyperbole)?  If the PMC Chair is a visible role, the community is  
already in
trouble.  The only role that a PMC Chair normally fills is getting  
the

quarterly report filed.  And this is why I feel strongly that we are
discussing the wrong thing to do.


I don't know that I agree completely with you about the role of PMC  
Chairs - sometimes a good PMC chair helps a project quite a bit


Projects should not be trained to rely upon an individual; they  
should be trained to act collaboratively.


Who can't agree with that statement.  But we're not debating that and  
it's true regardless of who is the PMC Chair.


This is a very convincing argument to me, especially since people  
without open source experience are already trained to look for  
who's in charge.


It's just not a useful argument for one way or the other.  One could  
just as easily assert that a new group of individuals with no  
experience in the ASF would view an ASF appointed PMC Chair as an  
authority figure, especially when this person would know so much more  
about the organization than they do.


In the ASF we do have PMC Chairs, period.

Now let's say, someone wins this debate on wether or not  having a  
PMC Chair from inside or outside the project is more or less likely  
to result in dependence.  I'm not of the opinion that we shouldn't be  
removing temptations or confusing dualities of the ASF while projects  
are in the incubator only for these projects to struggle with them  
after graduation.


Projects in the Incubator should be encouraged to try and *fail* over  
and over again till they get it.


-David


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (INCUBATOR-23) OpenEJB status page

[David Blevins (JIRA)]

[ 
http://issues.apache.org/jira/browse/INCUBATOR-23?page=comments#action_12420223 
] 

David Blevins commented on INCUBATOR-23:


thanks -- we'll have to get someone with sufficient privileges to close it.


 OpenEJB status page
 ---

  Key: INCUBATOR-23
  URL: http://issues.apache.org/jira/browse/INCUBATOR-23
  Project: Incubator
 Type: Task

   Components: site
 Reporter: David Blevins
  Attachments: openejb.patch

 Status page for OpenEJB

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (INCUBATOR-24) Setup OpenEJB mailing lists

[David Blevins (JIRA)]

[ 
http://issues.apache.org/jira/browse/INCUBATOR-24?page=comments#action_12420224 
] 

David Blevins commented on INCUBATOR-24:


thanks -- we'll have to get someone with sufficient privileges to close it.

 Setup OpenEJB mailing lists
 ---

  Key: INCUBATOR-24
  URL: http://issues.apache.org/jira/browse/INCUBATOR-24
  Project: Incubator
 Type: Task

 Reporter: David Blevins


 * [EMAIL PROTECTED] 
 * [EMAIL PROTECTED] 
 * [EMAIL PROTECTED] 
 http://wiki.apache.org/incubator/OpenEjbProposal

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [doc] IRC guidelines (was Re: Extensible Ajax Platform (XAP) Project Update)

[David Blevins]

On Jul 11, 2006, at 12:46 PM, Cliff Schmidt wrote:


IRC can be used by a podling to bring new people up to speed (e.g.
QA between available committers and interested users/contributors),
although such sessions should be archived and made available to those
not able to attend.  However, using IRC as a means to conduct
development/architecture discussions is discouraged.  Even with the
best intentions, experience has shown that it is difficult to maintain
such discussions without implicit decisions being made in the
process.


Personally, I'd cut out the part at the beginning which says what IRC  
can be used for and just start right out with Using IRC as a means  
to


Once you start listing what is allowed, it by default disallows  
anything not listed.  Unless that was the intent.


-David



Thoughts?

Cliff

On 7/11/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:

Jean-


 Given this paragraph in the committers guide [1]:

  Everything -- but everything-- inside the Apache world occurs  
or is reflected in email. As some people say, 'If it isn't in my  
email, it didn't happen.'


 Would adding this sentence to the end help?

Decisions only get made on Apache mail lists -- not anywhere
off list, such as IRC, IM, or private emails.


yes! I like it! I'd like to provide a patch, or go ahead if you have
write rights.

-Matthias

  btw. 404 for:
  http://incubator.apache.org/howtoparticipate.html

 oof! some post-docathon moldly links need to be cleaned up.  
thanks for

 pointing it out.

  -jean

 [1] http://incubator.apache.org/guides/committer.html

  
-

 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




--
Matthias Wessendorf

futher stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (INCUBATOR-23) OpenEJB status page

[David Blevins (JIRA)]

OpenEJB status page
---

 Key: INCUBATOR-23
 URL: http://issues.apache.org/jira/browse/INCUBATOR-23
 Project: Incubator
Type: Task

  Components: site  
Reporter: David Blevins


Status page for OpenEJB

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (INCUBATOR-23) OpenEJB status page

[David Blevins (JIRA)]

 [ http://issues.apache.org/jira/browse/INCUBATOR-23?page=all ]

David Blevins updated INCUBATOR-23:
---

Attachment: openejb.patch

 OpenEJB status page
 ---

  Key: INCUBATOR-23
  URL: http://issues.apache.org/jira/browse/INCUBATOR-23
  Project: Incubator
 Type: Task

   Components: site
 Reporter: David Blevins
  Attachments: openejb.patch

 Status page for OpenEJB

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (INCUBATOR-24) Setup OpenEJB mailing lists

[David Blevins (JIRA)]

Setup OpenEJB mailing lists
---

 Key: INCUBATOR-24
 URL: http://issues.apache.org/jira/browse/INCUBATOR-24
 Project: Incubator
Type: Task

Reporter: David Blevins


* [EMAIL PROTECTED] 
* [EMAIL PROTECTED] 
* [EMAIL PROTECTED] 

http://wiki.apache.org/incubator/OpenEjbProposal

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [continuum] incubator continuum / zone ?

[David Blevins]

Going to hop on that list and help you out over there.

On Jun 20, 2006, at 2:18 PM, Matthias Wessendorf wrote:


Since there is no heavy no no! don't use the MyFaces contnuum zone;
I'll bring this issue up to myfaces-dev list.

Regards,
Matthias

On 6/19/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:

would be another possibility.

but any objections when using the MyFaces continuum for ADF /  
Trinidad ?

Is is easy to manage, since MyFaces, MyFaces Tomahawk and MyFaces
Tobago use it already for ci.

Regards,
Matthias

On 6/19/06, David Blevins [EMAIL PROTECTED] wrote:
 Cc'ing infra@

 I'd volunteer to setup/maintain a ASF-wide continuum install if we
 wanted one.

 -David

 On Jun 19, 2006, at 12:37 PM, Matthias Wessendorf wrote:

  Hey,
 
  we'd like to add a nightly build support to the ADF Faces (aka
  Trinidad) donation.
  Since we are using Maven2 the continuum project sounds good!
 
  I don't know if there is a special Continuum Zone for Incubator
  projects.
  Another possibility could be using the MyFace zone, since the  
MyFaces

  PMC is the *sponsor* for this project.
 
  What do you think?
 
  Thanks,
  Matthias
 
   
-

  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: general- 
[EMAIL PROTECTED]

 


  
-

 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




--
Matthias Wessendorf
Aechterhoek 18
48282 Emsdetten
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com




--
Matthias Wessendorf
Aechterhoek 18
48282 Emsdetten
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [continuum] incubator continuum / zone ?

[David Blevins]

Cc'ing infra@

I'd volunteer to setup/maintain a ASF-wide continuum install if we  
wanted one.


-David

On Jun 19, 2006, at 12:37 PM, Matthias Wessendorf wrote:


Hey,

we'd like to add a nightly build support to the ADF Faces (aka
Trinidad) donation.
Since we are using Maven2 the continuum project sounds good!

I don't know if there is a special Continuum Zone for Incubator  
projects.

Another possibility could be using the MyFace zone, since the MyFaces
PMC is the *sponsor* for this project.

What do you think?

Thanks,
Matthias

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Accept OpenJPA as an Incubator Podling

[David Blevins]

+1

-David

On Mar 19, 2006, at 5:33 AM, Geir Magnusson Jr wrote:



What follows is the official proposal for OpenJPA.  The unofficial
version can be found here

  http://wiki.apache.org/incubator/OpenJPAProposal

Please vote on acceptance of this proposal.  The vote will run 1  
week until Sunday, March 26, 2006 or until all Incubator PMC  
members have voted.


[ ] +1 Accept the OpenJPA proposal
[ ] 0 Don't care
[ ] -1 Reject for the following reason :


== 
=



OpenJPA Project Proposal
=
OpenJPA will be an ASL-licensed implementation of the Java Persistence
API (JPA) which is defined as part of JSR-220.

Rationale
=
We think that Open JPA is something that will benefit from wide  
collaboration, being able to build a community of developers and  
committers that outlive the founders, and that will be embraced by  
other

Apache efforts, such as the Geronimo project as part of an EJB 3.0
container. Given the existing momentum forming behind JPA even at this
early stage, we are confident that an industrial-grade ASL
implementation of JSR220 will attract a diverse community.
Criteria

Meritocracy
===
The Open JPA committers recognize the desirability of building  
software

as a meritocracy and look forward to growing a healthy community of
developers to enhance the JPA APIs.

Community
=
The proposed committer community is includes members of the BEA JPA  
team

and several individuals from the Apache community.

Core Developers
===
Fourteen of the initial committers are BEA employees. One of those  
is a

committer on the Apache JDO project. We anticipate that five of these
fourteen will be involved in the core code development, and the other
nine will be involved in documentation and ongoing QA for the project.

Three of the initial committers are committers on the Geronimo  
project.

Two are IBM employees involved in the WebSphere product team. One is
from Intel.

Alignment
=
Open JPA will be a candidate for use in Geronimo as the default JPA
implementation. Other projects that have general-purpose JPA needs may
be users of the Open JPA project.

Open JPA has some level of alignment with the Apache DB project. In
particular, the Open JPA codebase already includes support for Derby
databases.

JPA is for use in any Java application, not just J2EE. Therefore, any
application that needs to do data persistence in the object/relational
style (including any application that currently uses Hibernate) will
benefit from Open JPA.

License
===
The existing codebase is owned by BEA and is subject to a proprietary
license. The applicable code will be relicensed under the Apache
Software License 2.0.


Avoiding the Warning Signs
==

Orphaned products
-
Open JPA is a derivative of the basis of the BEA WebLogic Server (WLS)
EJB3 JPA implementation, and so is an important piece of the BEA  
code base.


As this is a very eagerly anticipated specification for the Java
community, we expect that this project will continue to grow and  
develop
within its own community, and be embraced by other open source  
projects

(such as Geronimo) as well.

Inexperience with open source
-
The authors of the existing code (who will be part of the initial
committer list) have experience with open source development  
already, in

both professional and personal contexts. Examples: serp ([WWW]
http://serp.sourceforge.net) (used in Kodo currently), sqlline and  
jline

([WWW] http://sqlline.sourceforge.net and [WWW]
http://jline.sourceforge.net) (used by the Kodo development team, and
used by the Apache JDO team), Growl ([WWW] http://growl.info).

Four of the initial committers have extensive experience within the
Geronimo project, among other open-source projects.

Homogeneous developers
--
The members of the initial committer list have been working in a
distributed, multi-national, asynchronous environment for the last  
five

years, while working at SolarMetric. We had a team of up to 7 people
working from 6 different locations over the course of the last five  
years.


Reliance on Salaried Developers
---
Most of the developers are paid by their employer to contribute to  
this

project, but given the anticipation from the Java community for the a
JPA implementation and the committers' sense of ownership for the  
code,

the project would continue without issue if no salaried developers
contributed to the project.

No ties to other Apache products

Open JPA will likely be used by Geronimo, requires some Apache  
products
(regexp, commons collections, commons lang, commons pool), and  
supports

Apache commons logging.

A fascination with the Apache brand
---
We think that Open JPA is something that will benefit 

Re: ActiveMQ Graduation From Incubator

[David Blevins]

If you ask me what my opinion on OpenEJB's future or James' opinion  
on ActiveMQ's future, we'll both probably tell you TLP is a good goal  
eventually.


We've more or less been running as TLPs in relation to Geronimo for  
the past two plus years already, just at Codehaus.  We've seen how  
that plays out and we'd like to try a much more unified front for a  
while and see what shakes out.  We're all ready for a change in the  
status-quo.


The Geronimo world is awkward and unbalanced.  We have too tight  
integration with OpenEJB such that the standalone version of that  
completely disappeared.  We have too little integration with ActiveMQ  
such that the things you can do with standalone ActiveMQ you can't do  
with the Geronimo ActiveMQ.  We have parts of Geronimo which could  
very well become separately reusable components, like the transaction  
manager or the XBean code.  We're aren't successfully leveraging each  
other's communities to the fullest.  All in all, we don't make  
decisions together and lean on each other as much as we could.


I'd really like to see all our projects rolled up, balanced out, then  
split up again along possibly different lines with potentially more  
standalone pieces than we see now.


TLP is a good goal, but I really see value in the journey.

-David


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PROPOSAL] incubate OpenEJB as sub-projects of Geronimo

[David Blevins]

On Feb 14, 2006, at 7:35 PM, Noel J. Bergman wrote:


David,

The mentors should have karma to setup the status file.  At least  
one of
them has karma to the SVN access control lists.  Do we have all of  
the CLAs

and a Software Grant?


Noel or anyone,

Ismael needs to do a Software Grant (i think that's the doc) on  
behalf of Intalio for OpenEJB.  I'm not really sure what I'm doing,  
how do we go about this?



-David


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PROPOSAL] incubate OpenEJB as sub-projects of Geronimo

[David Blevins]

On Feb 14, 2006, at 7:35 PM, Noel J. Bergman wrote:


David,

The mentors should have karma to setup the status file.  At least  
one of
them has karma to the SVN access control lists.  Do we have all of  
the CLAs

and a Software Grant?


Ok.  I made nearly all the OpenEJB committers sign CLAs way back when  
Geronimo started as a preventative measure.  Is it possible to do a  
quick cross-check of our committers list and the CLAs on file?  Keep  
in mind I have no idea if what i'm asking is hard.



  If so, *after* the [EMAIL PROTECTED] mailing list
has been created, we can import the code under incubator/openejb.


Ok.

Thanks,
David

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PROPOSAL] incubate OpenEJB as sub-projects of Geronimo

[David Blevins]

On Feb 4, 2006, at 9:42 PM, Niclas Hedhman wrote:


On Friday 03 February 2006 03:50, David Blevins wrote:

OpenEJB has been proposed as a subproject of Geronimo.  See the
proposal here:


I think this is a good idea.

However, I would like to hear why OpenEJB was not part of Geronimo's
incubation?? After all, it was one of the cornerstones to get  
Geronimo off

the ground, wasn't it...


Nothing mysterious really.  At the time the team overlap was only two  
people (myself and RMH) and it was actually *during* incubation that  
the teams started coming together.


Now, I can't even keep track of all the people who wear both OpenEJB  
and Geronimo hats.



-David




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[PROPOSAL] incubate OpenEJB as sub-projects of Geronimo

[David Blevins]

Should have sent this email a much earlier as we voted quite some  
time ago.  Anyway,


OpenEJB has been proposed as a subproject of Geronimo.  See the  
proposal here:


http://wiki.apache.org/incubator/OpenEjbProposal

The Geronimo project has voted to be the sponsor of the OpenEJB.

The voting threads are
http://marc.theaimsgroup.com/?t=11335933571r=1w=2


-David


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PROPOSAL] incubate OpenEJB as sub-projects of Geronimo

[David Blevins]

On Feb 2, 2006, at 12:36 PM, Noel J. Bergman wrote:


David Blevins wrote:

As you know, this is a project that I would like to see moving into  
the ASF,

and Geronimo (in this case) is actually where it does belong, but ...


http://wiki.apache.org/incubator/OpenEjbProposal


Would you PLEASE revise whatever template you guys are copying from:


Just a note this proposal was done and voted on in November.  Just  
got really bogged down with Geronimo 1.0 and am now finally getting  
the OpenEJB ducks in a row.



New SVN module inside Geronimo SVN repo (openejb)


Not going to happen.  Code will be under the Incubator until it  
leaves.


Right, wasn't sure if i was supposed to think present tense or future  
tense on that one.


Minor point, but there is no such thing as a module.  Old CVS  
terminology.


Old habits.

Thanks,
David


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Directory exiting Incubator

[David Blevins]

[X] Graduate the Directory Project


-David

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Personal attacks and respect

[David Blevins]

On Fri, Jul 09, 2004 at 12:09:13AM +0200, Stephen McConnell wrote:
 Sander Striker wrote:
 
 From: Stephen McConnell [mailto:[EMAIL PROTECTED] 
 Sorry but Nicola Ken is not qualified.  I'm sorry Nicola but 
 you instigated this and only you can fix it.
 
 
 Stephen, saying that someone is not qualified to do X isn't constructive.
 Furthermore, it doesn't give me warm fuzzies reading a statement like
 that on a list like this one.  Or any list for that matter.
 
 Sander:
 
 I know where your coming from - but I'm kind of left without an option. 
 If you want to suggest a mechanisms for resolution I'm listening.
 

I really don't want to get caught in the cross-fire, but...you could
call each other up and talk/yell this out on the phone and get the
argument over quickly.

-David

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Graduate Geronimo from Incubator and recommend as top-level project

[David Blevins]

+1

On Thu, May 20, 2004 at 10:57:39PM -0400, Geir Magnusson Jr wrote:
 
 The Geronimo project has been in Incubation for almost 10 months.  In 
 those 10 months, the Geronimo project has developed a community, 
 developed a new codebase in an open and collaborative fashion, 
 weathered problems both internal and external, formed a functioning 
 group of committers to manage the day to day affairs of the project 
 (the PPMC), demonstrated collaboration with other OSS groups in the 
 enterprise software domain, and produced a milestone release of 
 software.
 
 Therefore, I believe the Geronimo project has satisfied the 
 requirements of the Apache Incubation process, namely :
 
  o  does collaborative development according to the ASF's
 philosophy and guidelines
 
  o  has a codebase that is properly licensed, has clear
 provenance, and conforms to the ASF's legal requirements
 for contributions
 
 Furthermore, I believe that the Incubator PMC, on behalf of the 
 Geronimo PPMC and the entire Geronimo community, should recommend to 
 the Apache Board of Directors to make the Geronimo project a top-level 
 Apache project.
 
 If this pleases the chair of the Incubator PMC, I request that members 
 of the Geronimo PPMC (which is the Incubator PMC and the Geronimo 
 committers) please vote :
 
 [ ] +1 - The Geronimo project has met the requirements
  for incubation and will be recommended to the
  board for TLP status
 
 [ ] -1 - The Geronimo project as not met the requirements
  for incubation
 
 This vote will run ~72 hours, closing at 23:59 EDT, Sunday May 23, 2004.
 
 geir
 
 
 -- 
 Geir Magnusson Jr   203-247-1713(m)
 [EMAIL PROTECTED] 
  
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Questions regarding a Clover donation

[David Blevins]

On Tue, Apr 13, 2004 at 04:48:23PM -0400, Alex Karasulu wrote:
 I was also thinking of approaching JetBrains for IDEA licenses for our 
 group as well.
 

Boy would I love an IDEA license.

-David

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]