perms on wiki
Hi, anyone can give me permissions to edit the wiki please? (i would like to create a proposal) 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: perms on wiki
Romain Manni-Bucau wrote: Hi, anyone can give me permissions to edit the wiki please? (i would like to create a proposal) Yes, but you do need to provide the crucial information: your wiki username. See the top-right of http://wiki.apache.org/incubator/ -David 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: perms on wiki
Hmm, seems i'm blocked (i tested apache and jira accounts probably too much times). i would like rmannibucau but not sure it is created. Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2013/9/17 David Crossley cross...@apache.org: Romain Manni-Bucau wrote: Hi, anyone can give me permissions to edit the wiki please? (i would like to create a proposal) Yes, but you do need to provide the crucial information: your wiki username. See the top-right of http://wiki.apache.org/incubator/ -David 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 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Usergrid BaaS Stack for Apache Incubator
On Tue, Sep 17, 2013 at 3:02 AM, John D. Ament john.d.am...@gmail.com wrote: Hi, So one nitpick. In your proposal, you link to https://github/usergrid but should probably be https://github.com/usergrid Doh! Thanks, good catch John. I just updated the wiki. I happened to get a demo of apigee a few months back at PhillyJUG. I was very impressed with the platform. I too was amazed, especially by how rapidly one could build web and mobile applications on it. I can't imagine having to have to start from scratch without it. Hence why it's such a good addition to the incubator IMO. On Mon, Sep 16, 2013 at 9:39 AM, Jim Jagielski j...@jagunet.com wrote: I would like to propose Usergrid, a multi-tenant Backend-as-a-Service stack for web mobile applications based on RESTful APIs, as an Apache Incubator podling. Here is a link to the proposal: https://wiki.apache.org/incubator/UsergridProposal It is also pasted below: = Usergrid Proposal = == Abstract == Usergrid is a multi-tenant Backend-as-a-Service stack for web mobile applications, based on RESTful APIs. == Proposal == Usergrid is an open-source Backend-as-a-Service (“BaaS” or “mBaaS”) composed of an integrated distributed NoSQL database, application layer and client tier with SDKs for developers looking to rapidly build web and/or mobile applications. It provides elementary services (user registration management, data storage, file storage, queues) and retrieval features (full text search, geolocation search, joins) to power common app features. It is a multi-tenant system designed for deployment to public cloud environments (such as Amazon Web Services, Rackspace, etc.) or to run on traditional server infrastructures so that anyone can run their own private BaaS deployment. For architects and back-end teams, it aims to provide a distributed, easily extendable, operationally predictable and highly scalable solution. For front-end developers, it aims to simplify the development process by enabling them to rapidly build and operate mobile and web applications without requiring backend expertise. == Background == Developing web or mobile applications obviously necessitates writing and maintaining more than just front-end code. Even simple applications can implicitly rely on server code being run to store users, perform database queries, serve images and video files, etc. Developing and maintaining such backend services requires skills not always available or expected of app development teams. Beyond that, the proliferation of apps inside of companies leads to the creation of many different, ad-hoc, unequally maintained backend solutions created by employees and contractors alike and hosted on a wide variety of environments. This is causing poor resource usage, operational issues, as well as security, privacy compliance concerns. In response to this problem, companies have long tried to standardize their server-side stack or unify them behind an ESB or API strategy. Backends-as-a-Service follow a similar approach but their unique characteristic is strongly tying 1) a persistence tier (typically a database), 2) a server-side application tier delivering a set of common services and 3) a set of client-side application interface mechanisms. For example, a BaaS could package 1) MongoDB with 2) a node.js application that offers access through 3) WebSockets. In the case of Usergrid, the trifecta is 1) Cassandra, 2) Java + Jersey and 3) a RESTful API. The Backend-as-a-Service approach has steadily gained popularity in the last few years with cloud providers such Parse.com, Stackmob.com and Kinvey.com, each operating tens of thousands of apps for tens of thousands of developers. The trend has already reached large organizations as well, with global companies such as Korea Telecom internally building a privately-run BaaS platform. But so far, there have been limited options for developers that want a non-proprietary, open option for hosting and providing these services themselves, or for enterprise and government users who want to provide these capabilities from their own data centers, especially on a very large scale. == Rationale == The issue this proposal deals with is implicit in the name. Backend-as-a-Service platforms are usually offered solely as proprietary cloud services. They are typically closed sourced, hosted on public clouds, and require subscription payment. Usergrid opens the playing field, by making a fully-featured BaaS platform freely available to all. This includes developers that previously could not afford them, such as mobile enthusiasts, small boutiques, and cost-sensitive startups. This also includes large companies that benefit from a reference implementation they can deploy in trust, or extend to their needs without losing time writing less-vetted, less-performant boilerplate functionality. Usergrid has been open source since 2011 and has
Re: perms on wiki
Here is my account login: RomainMannibucau Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2013/9/17 Romain Manni-Bucau rmannibu...@gmail.com: Hmm, seems i'm blocked (i tested apache and jira accounts probably too much times). i would like rmannibucau but not sure it is created. Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2013/9/17 David Crossley cross...@apache.org: Romain Manni-Bucau wrote: Hi, anyone can give me permissions to edit the wiki please? (i would like to create a proposal) Yes, but you do need to provide the crucial information: your wiki username. See the top-right of http://wiki.apache.org/incubator/ -David 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 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] jbatch impl @Apache?
wohuu, really great news! Does Scott and the orther guy(s) who worked on jBatch for IBM like to join the incubation? That's usually how things work. Even if they don't plan to add much to jBatch anymore, they still have a good amount of merrit. LieGrue, strub - Original Message - From: Romain Manni-Bucau rmannibu...@gmail.com To: general@incubator.apache.org Cc: Sent: Monday, 16 September 2013, 22:11 Subject: Re: [DISCUSS] jbatch impl @Apache? Hi, Now Scott informed us we can fork the RI ( http://apache-incubator-general.996316.n3.nabble.com/Re-DISCUSS-jbatch-impl-Apache-td36529.html) is it ok to start to write a proposal? Le 30 août 2013 15:23, Romain Manni-Bucau rmannibu...@gmail.com a écrit : Hi added some few modules: * shiro: nothing fancy just a simple SecurityService which check some perm to start/restart jobs - mainly to show how to write a custom one * extras: some readers/writers (flat, StAX) * beanio: integration with BeanIO framework I'll be quite off next week but any feedback + help to go ahead would be perfect *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/*http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/8/27 Romain Manni-Bucau rmannibu...@gmail.com Hi here is the fork: https://github.com/rmannibucau/batchee I created a parent module even if not yet mandatory since we will surely add a kind of extra module with readers, writers etc... I put a TODO.md with tasks i see as important to do mvn clean install will execute TCKs (normally it should be green in java 6 or 7) *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/*http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/8/27 Andy Van Den Heuvel andy.vandenheu...@gmail.com Great, Keep us posted. On Tue, Aug 27, 2013 at 10:36 AM, Romain Manni-Bucau rmannibu...@gmail.comwrote: Great to here, i plan to create a fork (maybe copy is more appropriated here) on my github for the end of this week (hopefully) then we can maybe discuss around it, does it work for you? *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/8/27 Mark Struberg strub...@yahoo.de I'd definitly need a jBatch here for some customers and I'd be happy to help with hacking, testing and even mentoring. LieGrue, strub - Original Message - From: Alan Cabrera l...@toolazydogs.com To: general@incubator.apache.org Cc: Sent: Monday, 26 August 2013, 17:15 Subject: Re: [DISCUSS] jbatch impl @Apache? Is there enough interest to generate an active community for this? Would it make more sense to do this work under Geronimo or TomEE? Regards, Alan On Aug 26, 2013, at 7:01 AM, Romain Manni-Bucau rmannibu...@gmail.com wrote: Hi As you probably know JavaEE 7 proposes a new spec called JBatch (aka JSR 352). I'd love to see an implementation @Apache. There is ATM only one implementation (spring-batch doesn't pass the full TCKs): the RI (done by IBM). AFAIK they doesn't aim to create a community about this spec but their implementation is under the license Apache v2 and starting to implement it from scratch i started to get something very close to them (i just started but seeing my classes so close i decided to stop my impl from scratch and see if forking wouldn't be a better/easier solution). Personally my plan would be to fork their code and clean/update it and create a community around it. About it i have some questions: 1) does it sound good? 2) any interested people? 3) how to process exactly? *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] jbatch impl @Apache?
Hi Scott said me this needs more discussion and I hope it will lead to a positive answer but it doesn't prevent us to go ahead I think Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2013/9/17 Mark Struberg strub...@yahoo.de: wohuu, really great news! Does Scott and the orther guy(s) who worked on jBatch for IBM like to join the incubation? That's usually how things work. Even if they don't plan to add much to jBatch anymore, they still have a good amount of merrit. LieGrue, strub - Original Message - From: Romain Manni-Bucau rmannibu...@gmail.com To: general@incubator.apache.org Cc: Sent: Monday, 16 September 2013, 22:11 Subject: Re: [DISCUSS] jbatch impl @Apache? Hi, Now Scott informed us we can fork the RI ( http://apache-incubator-general.996316.n3.nabble.com/Re-DISCUSS-jbatch-impl-Apache-td36529.html) is it ok to start to write a proposal? Le 30 août 2013 15:23, Romain Manni-Bucau rmannibu...@gmail.com a écrit : Hi added some few modules: * shiro: nothing fancy just a simple SecurityService which check some perm to start/restart jobs - mainly to show how to write a custom one * extras: some readers/writers (flat, StAX) * beanio: integration with BeanIO framework I'll be quite off next week but any feedback + help to go ahead would be perfect *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/*http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/8/27 Romain Manni-Bucau rmannibu...@gmail.com Hi here is the fork: https://github.com/rmannibucau/batchee I created a parent module even if not yet mandatory since we will surely add a kind of extra module with readers, writers etc... I put a TODO.md with tasks i see as important to do mvn clean install will execute TCKs (normally it should be green in java 6 or 7) *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/*http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/8/27 Andy Van Den Heuvel andy.vandenheu...@gmail.com Great, Keep us posted. On Tue, Aug 27, 2013 at 10:36 AM, Romain Manni-Bucau rmannibu...@gmail.comwrote: Great to here, i plan to create a fork (maybe copy is more appropriated here) on my github for the end of this week (hopefully) then we can maybe discuss around it, does it work for you? *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/8/27 Mark Struberg strub...@yahoo.de I'd definitly need a jBatch here for some customers and I'd be happy to help with hacking, testing and even mentoring. LieGrue, strub - Original Message - From: Alan Cabrera l...@toolazydogs.com To: general@incubator.apache.org Cc: Sent: Monday, 26 August 2013, 17:15 Subject: Re: [DISCUSS] jbatch impl @Apache? Is there enough interest to generate an active community for this? Would it make more sense to do this work under Geronimo or TomEE? Regards, Alan On Aug 26, 2013, at 7:01 AM, Romain Manni-Bucau rmannibu...@gmail.com wrote: Hi As you probably know JavaEE 7 proposes a new spec called JBatch (aka JSR 352). I'd love to see an implementation @Apache. There is ATM only one implementation (spring-batch doesn't pass the full TCKs): the RI (done by IBM). AFAIK they doesn't aim to create a community about this spec but their implementation is under the license Apache v2 and starting to implement it from scratch i started to get something very close to them (i just started but seeing my classes so close i decided to stop my impl from scratch and see if forking wouldn't be a better/easier solution). Personally my plan would be to fork their code and clean/update it and create a community around it. About it i have some questions: 1) does it sound good? 2) any interested people? 3) how to process exactly? *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github:
Re: perms on wiki
i just added you Am 17.09.13 09:51, schrieb Romain Manni-Bucau: Here is my account login: RomainMannibucau Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2013/9/17 Romain Manni-Bucau rmannibu...@gmail.com: Hmm, seems i'm blocked (i tested apache and jira accounts probably too much times). i would like rmannibucau but not sure it is created. Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2013/9/17 David Crossley cross...@apache.org: Romain Manni-Bucau wrote: Hi, anyone can give me permissions to edit the wiki please? (i would like to create a proposal) Yes, but you do need to provide the crucial information: your wiki username. See the top-right of http://wiki.apache.org/incubator/ -David 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 - 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: perms on wiki
Great thanks! Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2013/9/17 Christian Grobmeier grobme...@gmail.com: i just added you Am 17.09.13 09:51, schrieb Romain Manni-Bucau: Here is my account login: RomainMannibucau Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2013/9/17 Romain Manni-Bucau rmannibu...@gmail.com: Hmm, seems i'm blocked (i tested apache and jira accounts probably too much times). i would like rmannibucau but not sure it is created. Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2013/9/17 David Crossley cross...@apache.org: Romain Manni-Bucau wrote: Hi, anyone can give me permissions to edit the wiki please? (i would like to create a proposal) Yes, but you do need to provide the crucial information: your wiki username. See the top-right of http://wiki.apache.org/incubator/ -David 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 - 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
[PROPOSAL] BatchEE to implement JBatch @apache
Dear ASF members, I would like to propose the BatchEE project to the Incubator. The BatchEE proposal is available at: https://wiki.apache.org/incubator/BatchEEProposal I welcome your feedbacks and suggestions. Thanks! Here is a copy of the proposal: = BatchEE, JBatch Implementation = === Abstract === BatchEE will be an ASL-licensed implementation of the JBatch Specification which is defined as JSR-352 (for version 1.0). === Proposal === BatchEE specification is an effort for defining a standard API and way to write batches in Java. It is integrated with JavaEE (JTA, CDI) but works out of the box in a standalone environment. BatchEE Project is responsible for implementing the runtime container contract for the JBatch specification. Besides the implementation, BatchEE Project will implement the core built-in components that further simplifies the developer complex interactions with other Java EE specific enterprise operations. For example, it will define default reader/processor/writer for jdbc, jpa, xml/json/flat files... === Background === Until today writing batches in java meant using a proprietary framework and link to JavaEE was quite limited (or missing). JBatch defines an API fixing this issue and now developpers need a fix. === Rationale === Current JBatch specificatin is released, and only the reference implementation is available but not really intended to be maintained. Moreover multiple Apache projects (geronimo, TomEE, ...) will need an Apache compatible Jbatch implementation to go ahread and implement JavaEE 7. === Initial Goals === The initial goals of the BatchEE Project are * Fully implement the JSR-352 specification. * Attracts a community around the current code base. * Active relationship with the other dependent projects to further develop some useful batch components. == Current Status == === Meritocracy === Initial developer of the project is familiar with the meritocracy principles of Apache. He knows that the open source gets power from its great developers and freedom. He also developed some other open source projects. We will follow the normal meritocracy rules also with other potential contributors. === Community === There is a great community within the OpenEJB, OpenWebBeans, Geronimo and TomEE Apache projects. BatchEE project is very related with these projects and in the some cases, it enhances these projects. We are thinking that BatchEE project gets strong community because it complete the needed frameworks of a java developper and unifies the using of these projects. It simplifies the developer effort for building complex enterprise applications batches. === Core Developers === BatchEE project has been developing by the IBM then forked by Romain Manni-Bucau as a sole contributor. === Alignment === BacthEE project will be a candidate for use in Geronimo AS and TomEE as a default JBatch implementation. Other projects could benefit from the BatchEE project as a general purpose component and context management. BatchEE project is closely aligned with the OpenEJB and OpenWebBeans projects perfectly. It depends on these projects to satisfy its requirements (mainly tests). == Known Risks == === Orphaned products === Even if the initial committer of the project has no plan to leave the active development, it must necessary to get other committers for the project. So that it less dependent on the single developer. The source code of the project is well documented and new committers could easily grasp the details. Initial committer continues to support actively this project. === Inexperience with Open Source === Initial developer have worked on open source project before, including OpenEJB/TomEE, OpenWebBeans, XBean... === Homogeneous Developers === Altough the initial committer of the project is single, developer team may be increased within the active project lifecycle from the different locations. === Reliance on Salaried Developers === Project currently has no salaried developers. All the commitment is done by the volunteer developer. === Relationships with Other Apache Products === BatchEE will likely be used in the Geronimo and Apache TomEE. OpenWebBeans could bring added value for tests and integration with CDI. OpenEJB will be great to pass EE tests (JTA is mandatory and CDi a must have). === An Excessive Fascination with the Apache Brand === BatchEE project initial committer is the strong supporter of the open source projects. Initial committer of the project thinks that ASF has great place that provides wider colloboration and support of the open source project and it respects meritrocracy. Also, BatchEE project will surely be embraced by the Geronimo, TomEE, Camel and other Apache projects. BatchEE project is closely related with the some of the other Apache projects. == Documentation == Currently the main documentation of the project is contained in the README.md in the source repository (see next part). == Initial
Re: [PROPOSAL] BatchEE to implement JBatch @apache
It sounds interesting. I would be pleased to work as mentor of the project (if you want me ;)). Regards JB On 09/17/2013 12:21 PM, Romain Manni-Bucau wrote: Dear ASF members, I would like to propose the BatchEE project to the Incubator. The BatchEE proposal is available at: https://wiki.apache.org/incubator/BatchEEProposal I welcome your feedbacks and suggestions. Thanks! Here is a copy of the proposal: = BatchEE, JBatch Implementation = === Abstract === BatchEE will be an ASL-licensed implementation of the JBatch Specification which is defined as JSR-352 (for version 1.0). === Proposal === BatchEE specification is an effort for defining a standard API and way to write batches in Java. It is integrated with JavaEE (JTA, CDI) but works out of the box in a standalone environment. BatchEE Project is responsible for implementing the runtime container contract for the JBatch specification. Besides the implementation, BatchEE Project will implement the core built-in components that further simplifies the developer complex interactions with other Java EE specific enterprise operations. For example, it will define default reader/processor/writer for jdbc, jpa, xml/json/flat files... === Background === Until today writing batches in java meant using a proprietary framework and link to JavaEE was quite limited (or missing). JBatch defines an API fixing this issue and now developpers need a fix. === Rationale === Current JBatch specificatin is released, and only the reference implementation is available but not really intended to be maintained. Moreover multiple Apache projects (geronimo, TomEE, ...) will need an Apache compatible Jbatch implementation to go ahread and implement JavaEE 7. === Initial Goals === The initial goals of the BatchEE Project are * Fully implement the JSR-352 specification. * Attracts a community around the current code base. * Active relationship with the other dependent projects to further develop some useful batch components. == Current Status == === Meritocracy === Initial developer of the project is familiar with the meritocracy principles of Apache. He knows that the open source gets power from its great developers and freedom. He also developed some other open source projects. We will follow the normal meritocracy rules also with other potential contributors. === Community === There is a great community within the OpenEJB, OpenWebBeans, Geronimo and TomEE Apache projects. BatchEE project is very related with these projects and in the some cases, it enhances these projects. We are thinking that BatchEE project gets strong community because it complete the needed frameworks of a java developper and unifies the using of these projects. It simplifies the developer effort for building complex enterprise applications batches. === Core Developers === BatchEE project has been developing by the IBM then forked by Romain Manni-Bucau as a sole contributor. === Alignment === BacthEE project will be a candidate for use in Geronimo AS and TomEE as a default JBatch implementation. Other projects could benefit from the BatchEE project as a general purpose component and context management. BatchEE project is closely aligned with the OpenEJB and OpenWebBeans projects perfectly. It depends on these projects to satisfy its requirements (mainly tests). == Known Risks == === Orphaned products === Even if the initial committer of the project has no plan to leave the active development, it must necessary to get other committers for the project. So that it less dependent on the single developer. The source code of the project is well documented and new committers could easily grasp the details. Initial committer continues to support actively this project. === Inexperience with Open Source === Initial developer have worked on open source project before, including OpenEJB/TomEE, OpenWebBeans, XBean... === Homogeneous Developers === Altough the initial committer of the project is single, developer team may be increased within the active project lifecycle from the different locations. === Reliance on Salaried Developers === Project currently has no salaried developers. All the commitment is done by the volunteer developer. === Relationships with Other Apache Products === BatchEE will likely be used in the Geronimo and Apache TomEE. OpenWebBeans could bring added value for tests and integration with CDI. OpenEJB will be great to pass EE tests (JTA is mandatory and CDi a must have). === An Excessive Fascination with the Apache Brand === BatchEE project initial committer is the strong supporter of the open source projects. Initial committer of the project thinks that ASF has great place that provides wider colloboration and support of the open source project and it respects meritrocracy. Also, BatchEE project will surely be embraced by the Geronimo, TomEE, Camel and other Apache projects. BatchEE project is closely related with the some of the other Apache
Re: [PROPOSAL] BatchEE to implement JBatch @apache
added you, thks Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2013/9/17 Jean-Baptiste Onofré j...@nanthrax.net: It sounds interesting. I would be pleased to work as mentor of the project (if you want me ;)). Regards JB On 09/17/2013 12:21 PM, Romain Manni-Bucau wrote: Dear ASF members, I would like to propose the BatchEE project to the Incubator. The BatchEE proposal is available at: https://wiki.apache.org/incubator/BatchEEProposal I welcome your feedbacks and suggestions. Thanks! Here is a copy of the proposal: = BatchEE, JBatch Implementation = === Abstract === BatchEE will be an ASL-licensed implementation of the JBatch Specification which is defined as JSR-352 (for version 1.0). === Proposal === BatchEE specification is an effort for defining a standard API and way to write batches in Java. It is integrated with JavaEE (JTA, CDI) but works out of the box in a standalone environment. BatchEE Project is responsible for implementing the runtime container contract for the JBatch specification. Besides the implementation, BatchEE Project will implement the core built-in components that further simplifies the developer complex interactions with other Java EE specific enterprise operations. For example, it will define default reader/processor/writer for jdbc, jpa, xml/json/flat files... === Background === Until today writing batches in java meant using a proprietary framework and link to JavaEE was quite limited (or missing). JBatch defines an API fixing this issue and now developpers need a fix. === Rationale === Current JBatch specificatin is released, and only the reference implementation is available but not really intended to be maintained. Moreover multiple Apache projects (geronimo, TomEE, ...) will need an Apache compatible Jbatch implementation to go ahread and implement JavaEE 7. === Initial Goals === The initial goals of the BatchEE Project are * Fully implement the JSR-352 specification. * Attracts a community around the current code base. * Active relationship with the other dependent projects to further develop some useful batch components. == Current Status == === Meritocracy === Initial developer of the project is familiar with the meritocracy principles of Apache. He knows that the open source gets power from its great developers and freedom. He also developed some other open source projects. We will follow the normal meritocracy rules also with other potential contributors. === Community === There is a great community within the OpenEJB, OpenWebBeans, Geronimo and TomEE Apache projects. BatchEE project is very related with these projects and in the some cases, it enhances these projects. We are thinking that BatchEE project gets strong community because it complete the needed frameworks of a java developper and unifies the using of these projects. It simplifies the developer effort for building complex enterprise applications batches. === Core Developers === BatchEE project has been developing by the IBM then forked by Romain Manni-Bucau as a sole contributor. === Alignment === BacthEE project will be a candidate for use in Geronimo AS and TomEE as a default JBatch implementation. Other projects could benefit from the BatchEE project as a general purpose component and context management. BatchEE project is closely aligned with the OpenEJB and OpenWebBeans projects perfectly. It depends on these projects to satisfy its requirements (mainly tests). == Known Risks == === Orphaned products === Even if the initial committer of the project has no plan to leave the active development, it must necessary to get other committers for the project. So that it less dependent on the single developer. The source code of the project is well documented and new committers could easily grasp the details. Initial committer continues to support actively this project. === Inexperience with Open Source === Initial developer have worked on open source project before, including OpenEJB/TomEE, OpenWebBeans, XBean... === Homogeneous Developers === Altough the initial committer of the project is single, developer team may be increased within the active project lifecycle from the different locations. === Reliance on Salaried Developers === Project currently has no salaried developers. All the commitment is done by the volunteer developer. === Relationships with Other Apache Products === BatchEE will likely be used in the Geronimo and Apache TomEE. OpenWebBeans could bring added value for tests and integration with CDI. OpenEJB will be great to pass EE tests (JTA is mandatory and CDi a must have). === An Excessive Fascination with the Apache Brand === BatchEE project initial committer is the strong supporter of the open source projects. Initial
Re: [PROPOSAL] Usergrid BaaS Stack for Apache Incubator
On Mon, Sep 16, 2013 at 3:39 PM, Jim Jagielski j...@jagunet.com wrote: I would like to propose Usergrid, a multi-tenant Backend-as-a-Service stack for web mobile applications based on RESTful APIs, as an Apache Incubator podling. Here is a link to the proposal: https://wiki.apache.org/incubator/UsergridProposal It is also pasted below: = Usergrid Proposal = == Abstract == Usergrid is a multi-tenant Backend-as-a-Service stack for web mobile applications, based on RESTful APIs. == Proposal == Usergrid is an open-source Backend-as-a-Service (“BaaS” or “mBaaS”) composed of an integrated distributed NoSQL database, application layer and client tier with SDKs for developers looking to rapidly build web and/or mobile applications. It provides elementary services (user registration management, data storage, file storage, queues) and retrieval features (full text search, geolocation search, joins) to power common app features. It is a multi-tenant system designed for deployment to public cloud environments (such as Amazon Web Services, Rackspace, etc.) or to run on traditional server infrastructures so that anyone can run their own private BaaS deployment. For architects and back-end teams, it aims to provide a distributed, easily extendable, operationally predictable and highly scalable solution. For front-end developers, it aims to simplify the development process by enabling them to rapidly build and operate mobile and web applications without requiring backend expertise. == Background == Developing web or mobile applications obviously necessitates writing and maintaining more than just front-end code. Even simple applications can implicitly rely on server code being run to store users, perform database queries, serve images and video files, etc. Developing and maintaining such backend services requires skills not always available or expected of app development teams. Beyond that, the proliferation of apps inside of companies leads to the creation of many different, ad-hoc, unequally maintained backend solutions created by employees and contractors alike and hosted on a wide variety of environments. This is causing poor resource usage, operational issues, as well as security, privacy compliance concerns. In response to this problem, companies have long tried to standardize their server-side stack or unify them behind an ESB or API strategy. Backends-as-a-Service follow a similar approach but their unique characteristic is strongly tying 1) a persistence tier (typically a database), 2) a server-side application tier delivering a set of common services and 3) a set of client-side application interface mechanisms. For example, a BaaS could package 1) MongoDB with 2) a node.js application that offers access through 3) WebSockets. In the case of Usergrid, the trifecta is 1) Cassandra, 2) Java + Jersey and 3) a RESTful API. The Backend-as-a-Service approach has steadily gained popularity in the last few years with cloud providers such Parse.com, Stackmob.com and Kinvey.com, each operating tens of thousands of apps for tens of thousands of developers. The trend has already reached large organizations as well, with global companies such as Korea Telecom internally building a privately-run BaaS platform. But so far, there have been limited options for developers that want a non-proprietary, open option for hosting and providing these services themselves, or for enterprise and government users who want to provide these capabilities from their own data centers, especially on a very large scale. == Rationale == The issue this proposal deals with is implicit in the name. Backend-as-a-Service platforms are usually offered solely as proprietary cloud services. They are typically closed sourced, hosted on public clouds, and require subscription payment. Usergrid opens the playing field, by making a fully-featured BaaS platform freely available to all. This includes developers that previously could not afford them, such as mobile enthusiasts, small boutiques, and cost-sensitive startups. This also includes large companies that benefit from a reference implementation they can deploy in trust, or extend to their needs without losing time writing less-vetted, less-performant boilerplate functionality. Usergrid has been open source since 2011 and has grown as an independent project, garnering 11 primary committers, 35 total contributors, 260+ participants on its mailing list, with 3,700+ commits, 200+ external contributions, 350+ stars and 100+ forks on Github, not to mention several large scale production deployments at major global companies in the media, retail, telecommunication and government spaces. The Apache Software Foundation's Way, by putting community before the code, will help Usergrid establish a vibrant, more diverse community to provide these features freely to downstream users. The incubation process will help
Re: [PROPOSAL] BatchEE to implement JBatch @apache
Added you as initial committer. Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2013/9/17 Gerhard Petracek gpetra...@apache.org: hi romain, i would be ready to help with it as well. regards, gerhard 2013/9/17 Romain Manni-Bucau rmannibu...@gmail.com added you, thks Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2013/9/17 Jean-Baptiste Onofré j...@nanthrax.net: It sounds interesting. I would be pleased to work as mentor of the project (if you want me ;)). Regards JB On 09/17/2013 12:21 PM, Romain Manni-Bucau wrote: Dear ASF members, I would like to propose the BatchEE project to the Incubator. The BatchEE proposal is available at: https://wiki.apache.org/incubator/BatchEEProposal I welcome your feedbacks and suggestions. Thanks! Here is a copy of the proposal: = BatchEE, JBatch Implementation = === Abstract === BatchEE will be an ASL-licensed implementation of the JBatch Specification which is defined as JSR-352 (for version 1.0). === Proposal === BatchEE specification is an effort for defining a standard API and way to write batches in Java. It is integrated with JavaEE (JTA, CDI) but works out of the box in a standalone environment. BatchEE Project is responsible for implementing the runtime container contract for the JBatch specification. Besides the implementation, BatchEE Project will implement the core built-in components that further simplifies the developer complex interactions with other Java EE specific enterprise operations. For example, it will define default reader/processor/writer for jdbc, jpa, xml/json/flat files... === Background === Until today writing batches in java meant using a proprietary framework and link to JavaEE was quite limited (or missing). JBatch defines an API fixing this issue and now developpers need a fix. === Rationale === Current JBatch specificatin is released, and only the reference implementation is available but not really intended to be maintained. Moreover multiple Apache projects (geronimo, TomEE, ...) will need an Apache compatible Jbatch implementation to go ahread and implement JavaEE 7. === Initial Goals === The initial goals of the BatchEE Project are * Fully implement the JSR-352 specification. * Attracts a community around the current code base. * Active relationship with the other dependent projects to further develop some useful batch components. == Current Status == === Meritocracy === Initial developer of the project is familiar with the meritocracy principles of Apache. He knows that the open source gets power from its great developers and freedom. He also developed some other open source projects. We will follow the normal meritocracy rules also with other potential contributors. === Community === There is a great community within the OpenEJB, OpenWebBeans, Geronimo and TomEE Apache projects. BatchEE project is very related with these projects and in the some cases, it enhances these projects. We are thinking that BatchEE project gets strong community because it complete the needed frameworks of a java developper and unifies the using of these projects. It simplifies the developer effort for building complex enterprise applications batches. === Core Developers === BatchEE project has been developing by the IBM then forked by Romain Manni-Bucau as a sole contributor. === Alignment === BacthEE project will be a candidate for use in Geronimo AS and TomEE as a default JBatch implementation. Other projects could benefit from the BatchEE project as a general purpose component and context management. BatchEE project is closely aligned with the OpenEJB and OpenWebBeans projects perfectly. It depends on these projects to satisfy its requirements (mainly tests). == Known Risks == === Orphaned products === Even if the initial committer of the project has no plan to leave the active development, it must necessary to get other committers for the project. So that it less dependent on the single developer. The source code of the project is well documented and new committers could easily grasp the details. Initial committer continues to support actively this project. === Inexperience with Open Source === Initial developer have worked on open source project before, including OpenEJB/TomEE, OpenWebBeans, XBean... === Homogeneous Developers === Altough the initial committer of the project is single, developer team may be increased within the active project lifecycle from the different locations. === Reliance on Salaried Developers === Project
Re: [PROPOSAL] Usergrid BaaS Stack for Apache Incubator
On Tue, Sep 17, 2013 at 1:57 PM, Lieven Govaerts lieven.govae...@gmail.com wrote: SNIP ... As I'm setting up a similar infrastructure for a mobile application now, this project interests me a lot. I have made some different design choices so it'll be interesting to compare the benefits of my approach against choices made by the usergrid team. We welcome your opinions, and your involvement. This is exactly what we've been looking forward to. I'll dig into the code more deeply and join (with contributions) were I can. Awesome! Definitely a good addition to the apache incubator! Thanks, -- Alex - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] jbatch impl @Apache?
Mark, Let me confirm Romain's answer by saying that we haven't decided on a direction at this time. I do plan on keeping an eye on the project during incubation in the meantime. I'll also point out that issues concerning the specification (and the TCK) can be raised and discussed via the mailing list of the java.net 'jbatch' project which we used to develop the RI and TCK. https://java.net/projects/jbatch/ -- Scott Kurz WebSphere Batch / Compute Grid Development T/L 295-5649; External Phone 845-435-5649 sk...@us.ibm.com From: Romain Manni-Bucau rmannibu...@gmail.com To: general@incubator.apache.org, Mark Struberg strub...@yahoo.de, Date: 09/17/2013 04:04 AM Subject:Re: [DISCUSS] jbatch impl @Apache? Hi Scott said me this needs more discussion and I hope it will lead to a positive answer but it doesn't prevent us to go ahead I think Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2013/9/17 Mark Struberg strub...@yahoo.de: wohuu, really great news! Does Scott and the orther guy(s) who worked on jBatch for IBM like to join the incubation? That's usually how things work. Even if they don't plan to add much to jBatch anymore, they still have a good amount of merrit. LieGrue, strub - Original Message - From: Romain Manni-Bucau rmannibu...@gmail.com To: general@incubator.apache.org Cc: Sent: Monday, 16 September 2013, 22:11 Subject: Re: [DISCUSS] jbatch impl @Apache? Hi, Now Scott informed us we can fork the RI ( http://apache-incubator-general.996316.n3.nabble.com/Re-DISCUSS-jbatch-impl-Apache-td36529.html ) is it ok to start to write a proposal? Le 30 août 2013 15:23, Romain Manni-Bucau rmannibu...@gmail.com a écrit : Hi added some few modules: * shiro: nothing fancy just a simple SecurityService which check some perm to start/restart jobs - mainly to show how to write a custom one * extras: some readers/writers (flat, StAX) * beanio: integration with BeanIO framework I'll be quite off next week but any feedback + help to go ahead would be perfect *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/*http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/8/27 Romain Manni-Bucau rmannibu...@gmail.com Hi here is the fork: https://github.com/rmannibucau/batchee I created a parent module even if not yet mandatory since we will surely add a kind of extra module with readers, writers etc... I put a TODO.md with tasks i see as important to do mvn clean install will execute TCKs (normally it should be green in java 6 or 7) *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/*http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/8/27 Andy Van Den Heuvel andy.vandenheu...@gmail.com Great, Keep us posted. On Tue, Aug 27, 2013 at 10:36 AM, Romain Manni-Bucau rmannibu...@gmail.comwrote: Great to here, i plan to create a fork (maybe copy is more appropriated here) on my github for the end of this week (hopefully) then we can maybe discuss around it, does it work for you? *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/8/27 Mark Struberg strub...@yahoo.de I'd definitly need a jBatch here for some customers and I'd be happy to help with hacking, testing and even mentoring. LieGrue, strub - Original Message - From: Alan Cabrera l...@toolazydogs.com To: general@incubator.apache.org Cc: Sent: Monday, 26 August 2013, 17:15 Subject: Re: [DISCUSS] jbatch impl @Apache? Is there enough interest to generate an active community for this? Would it make more sense to do this work under Geronimo or TomEE? Regards, Alan On Aug 26, 2013, at 7:01 AM, Romain Manni-Bucau rmannibu...@gmail.com wrote: Hi As you probably know JavaEE 7 proposes a new spec called JBatch (aka JSR 352). I'd love to see an implementation @Apache. There is ATM only one implementation (spring-batch doesn't pass the full TCKs): the RI (done by IBM). AFAIK they doesn't aim to create a community about this spec but their
Re: [DISCUSS] Release of Apache Allura (incubating) v1.0.0
sebb, Thanks for your feedback. I have created a wiki page at https://forge-allura.apache.org/p/allura/wiki/ASF%20Release%20Notes/ to gather all the feedback we've gotten, and I will begin correcting the issues raised. Once those have been addressed, I think we will do a 1.0.1 release to get the entire process correct. I had one question regarding the NOTICE and LICENSE files issue that you mentioned on the [VOTE] thread. We were considering, in the future, potentially releasing each of the Allura and Forge sub-packages separately on pypi to ease configuration of an Allura system, which is why were providing separate NOTICE and LICENSE files for each sub-package. Is the separate pypi release something that the ASF release is amenable to, and, if so, should we still stick to a single NOTICE or single NOTICE LICENSE file? Thanks, Cory On Mon, Sep 16, 2013 at 6:35 PM, sebb seb...@gmail.com wrote: Sorry, again forgot: It's useful to have a link to the RAT report (or equivalent) showing that files have the appropriate license headers. On 16 September 2013 23:33, sebb seb...@gmail.com wrote: Forgot to say: AFAIK, Git tags are not immutable, so the vote e-mail should contain the hash for the tag. On 16 September 2013 23:30, sebb seb...@gmail.com wrote: On 16 September 2013 14:17, Dave Brondsema d...@brondsema.net wrote: IPMC members, hello again. We are still waiting for your votes to be cast for Allura's first release: see vote thread Aug portion [1] and Sept portion [2] If there is anything the Allura PPMC can provide or do, to help, please let us know. I think we're just waiting on you all, though. I see there is a KEYS file is stored at http://www.apache.org/dist/incubator/allura/KEYS which is the usual location; however it helps to include it in vote e-mails. I hope some of the energy seen recently in discussing the Monitoring proposal and welcoming Storm can also be applied to help us through our incubation. Thanks, Dave [1] http://mail-archives.apache.org/mod_mbox/incubator-general/201308.mbox/%3CCAGN0FaTfgodR_vkuKTvO6EySfRKuZQJmOm%3Dm4K0mGQhnefD2ng%40mail.gmail.com%3E [2] http://mail-archives.apache.org/mod_mbox/incubator-general/201309.mbox/%3C5227383D.3070401%40brondsema.net%3E On 09/11/2013 03:14 AM, Ross Gardler wrote: On 10 September 2013 10:31, Dave Brondsema d...@brondsema.net wrote: On 9/9/13 12:22 PM, Marvin Humphrey wrote: On Mon, Sep 9, 2013 at 6:47 AM, Rich Bowen rbo...@rcbowen.com wrote: Hmm. Did we do something wrong with our call for vote? ... Can anyone suggest any reason why we've gotten ZERO response to this message or to Dave's followup? Allura has four Mentors. You've voted, but where are the others? I wonder this as well :( This one has been relocating his family from the UK to the US and is a long way behind on non-work related activities. The good news is that I'm now in a permanent home for the next 10 months and my furniture is clearing customs as we speak. My family and I will have chairs to sit on soon :-D Apologies for not being present for your first release vote. Ross -- Dave Brondsema : d...@brondsema.net http://www.brondsema.net : personal http://www.splike.com : programming - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] BatchEE to implement JBatch @apache
This is interesting to me, not sure if I have the time to help much, but I should be able to find some excuses to let my employers help fund (by letting me use work time) work on this! On 17 September 2013 11:21, Romain Manni-Bucau rmannibu...@gmail.comwrote: Dear ASF members, I would like to propose the BatchEE project to the Incubator. The BatchEE proposal is available at: https://wiki.apache.org/incubator/BatchEEProposal I welcome your feedbacks and suggestions. Thanks! Here is a copy of the proposal: = BatchEE, JBatch Implementation = === Abstract === BatchEE will be an ASL-licensed implementation of the JBatch Specification which is defined as JSR-352 (for version 1.0). === Proposal === BatchEE specification is an effort for defining a standard API and way to write batches in Java. It is integrated with JavaEE (JTA, CDI) but works out of the box in a standalone environment. BatchEE Project is responsible for implementing the runtime container contract for the JBatch specification. Besides the implementation, BatchEE Project will implement the core built-in components that further simplifies the developer complex interactions with other Java EE specific enterprise operations. For example, it will define default reader/processor/writer for jdbc, jpa, xml/json/flat files... === Background === Until today writing batches in java meant using a proprietary framework and link to JavaEE was quite limited (or missing). JBatch defines an API fixing this issue and now developpers need a fix. === Rationale === Current JBatch specificatin is released, and only the reference implementation is available but not really intended to be maintained. Moreover multiple Apache projects (geronimo, TomEE, ...) will need an Apache compatible Jbatch implementation to go ahread and implement JavaEE 7. === Initial Goals === The initial goals of the BatchEE Project are * Fully implement the JSR-352 specification. * Attracts a community around the current code base. * Active relationship with the other dependent projects to further develop some useful batch components. == Current Status == === Meritocracy === Initial developer of the project is familiar with the meritocracy principles of Apache. He knows that the open source gets power from its great developers and freedom. He also developed some other open source projects. We will follow the normal meritocracy rules also with other potential contributors. === Community === There is a great community within the OpenEJB, OpenWebBeans, Geronimo and TomEE Apache projects. BatchEE project is very related with these projects and in the some cases, it enhances these projects. We are thinking that BatchEE project gets strong community because it complete the needed frameworks of a java developper and unifies the using of these projects. It simplifies the developer effort for building complex enterprise applications batches. === Core Developers === BatchEE project has been developing by the IBM then forked by Romain Manni-Bucau as a sole contributor. === Alignment === BacthEE project will be a candidate for use in Geronimo AS and TomEE as a default JBatch implementation. Other projects could benefit from the BatchEE project as a general purpose component and context management. BatchEE project is closely aligned with the OpenEJB and OpenWebBeans projects perfectly. It depends on these projects to satisfy its requirements (mainly tests). == Known Risks == === Orphaned products === Even if the initial committer of the project has no plan to leave the active development, it must necessary to get other committers for the project. So that it less dependent on the single developer. The source code of the project is well documented and new committers could easily grasp the details. Initial committer continues to support actively this project. === Inexperience with Open Source === Initial developer have worked on open source project before, including OpenEJB/TomEE, OpenWebBeans, XBean... === Homogeneous Developers === Altough the initial committer of the project is single, developer team may be increased within the active project lifecycle from the different locations. === Reliance on Salaried Developers === Project currently has no salaried developers. All the commitment is done by the volunteer developer. === Relationships with Other Apache Products === BatchEE will likely be used in the Geronimo and Apache TomEE. OpenWebBeans could bring added value for tests and integration with CDI. OpenEJB will be great to pass EE tests (JTA is mandatory and CDi a must have). === An Excessive Fascination with the Apache Brand === BatchEE project initial committer is the strong supporter of the open source projects. Initial committer of the project thinks that ASF has great place that provides wider colloboration and support of the open source project and it respects
Re: [DISCUSS] Release of Apache Allura (incubating) v1.0.0
On Tue, Sep 17, 2013 at 12:41 PM, Cory Johns john...@gmail.com wrote: I had one question regarding the NOTICE and LICENSE files issue that you mentioned on the [VOTE] thread. We were considering, in the future, potentially releasing each of the Allura and Forge sub-packages separately on pypi to ease configuration of an Allura system, which is why were providing separate NOTICE and LICENSE files for each sub-package. The key principle is that the top-level LICENSE and NOTICE must represent the exact contents of the specific distribution they reside in. * The licensing of nested dependencies must be accounted for at the top level. Consumers shouldn't have to hunt through every file in every directory of the source tree to discover the complete licensing of the product they're consuming. Bundling dependency licensing info as is may satisfy hard-and-fast requirements for some dependency licenses, but it is ASF policy to provide flattened licensing info at the top level of our distros for the benefit of our users. * Don't include entries in the top-level LICENSE and NOTICE for dependencies which are **not** bundled in the distribution in question. If consumers are obtaining those bits from an outside source, they must obtain the licensing info for those bits from the same outside source. * If you provide convenience binaries in addition to your canonical source release artifacts and those binaries bundle dependencies which are not bundled with the source release, then the LICENSE and NOTICE for the binary artifacts must account for the additional IP and will presumably differ from the LICENSE and NOTICE of the source release. * If you provide a -deps bundle to complement the primary release artifacts, it should have its own LICENSE and NOTICE info which varies independently and represents its own exact contents. Note that since these are ASF policies which have evolved over the years rather than absolute legal requirements, compliance varies somewhat across TLPs and time. The Incubator PMC will also sometimes let licensing documentation bugs go, depending on their impact on downstream consumers and assuming that they don't cause the release to violate anybody's license. However, it's definitely in your interest to make a best effort to adhere to the policy. Is the separate pypi release something that the ASF release is amenable to, and, if so, should we still stick to a single NOTICE or single NOTICE LICENSE file? Any artifact that is being distributed through Apache channels is supposed to adhere to our policies. Convenience binaries and derived source releases are alike in that both are downstream from the canonical source release, so to speak. I infer from your description that in this case the PyPI-flavored release artifacts consist of subsets of files extracted from the canonical source release. The same key principle applies: LICENSE and NOTICE must represent the exact contents of the specific distribution they reside in. That means if there are dependencies in the canonical source release which are not present in the PyPI release, the PyPI distro's LICENSE and NOTICE files need to be edited down to remove any licensing info which does not apply. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[VOTE] first milestone release of Apache Drill (incubating)
We've held a vote on drill-dev to release the first milestone release. The vote thread can be found here: http://mail-archives.apache.org/mod_mbox/incubator-drill-dev/201309.mbox/%3ccaka9qdkmxjp-r8v+zwabm5e4b5osrypjyp+dupvq2lr-d70...@mail.gmail.com%3E The vote passed with 4 x +1 binding votes 7 x +1 non-binding votes An additional non-binding +1 vote was received after the vote closed. A summary email can be found here: http://mail-archives.apache.org/mod_mbox/incubator-drill-dev/201309.mbox/%3CCAKa9qDn1+TnKVP=p_=Lh==mOS=azctuz6_qvsm4u3z4gdhh...@mail.gmail.com%3E The source only release artifactscan be found together with signatures here: http://people.apache.org/~jacques/apache-drill-1.0.0-m1.rc4/ Please vote on this release
Re: [VOTE] first milestone release of Apache Drill (incubating)
Wonderful. On Sep 17, 2013, at 3:29 PM, Ted Dunning wrote: We've held a vote on drill-dev to release the first milestone release. The vote thread can be found here: http://mail-archives.apache.org/mod_mbox/incubator-drill-dev/201309.mbox/%3ccaka9qdkmxjp-r8v+zwabm5e4b5osrypjyp+dupvq2lr-d70...@mail.gmail.com%3E The vote passed with 4 x +1 binding votes 7 x +1 non-binding votes An additional non-binding +1 vote was received after the vote closed. A summary email can be found here: http://mail-archives.apache.org/mod_mbox/incubator-drill-dev/201309.mbox/%3CCAKa9qDn1+TnKVP=p_=Lh==mOS=azctuz6_qvsm4u3z4gdhh...@mail.gmail.com%3E The source only release artifactscan be found together with signatures here: http://people.apache.org/~jacques/apache-drill-1.0.0-m1.rc4/ Please vote on this release - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] first milestone release of Apache Drill (incubating)
Lest anybody not understand my implicit vote: +1 (binding) On Tue, Sep 17, 2013 at 5:13 PM, Dave Fisher dave2w...@comcast.net wrote: Wonderful. On Sep 17, 2013, at 3:29 PM, Ted Dunning wrote: We've held a vote on drill-dev to release the first milestone release. The vote thread can be found here: http://mail-archives.apache.org/mod_mbox/incubator-drill-dev/201309.mbox/%3ccaka9qdkmxjp-r8v+zwabm5e4b5osrypjyp+dupvq2lr-d70...@mail.gmail.com%3E The vote passed with 4 x +1 binding votes 7 x +1 non-binding votes An additional non-binding +1 vote was received after the vote closed. A summary email can be found here: http://mail-archives.apache.org/mod_mbox/incubator-drill-dev/201309.mbox/%3CCAKa9qDn1+TnKVP=p_=Lh==mOS=azctuz6_qvsm4u3z4gdhh...@mail.gmail.com%3E The source only release artifactscan be found together with signatures here: http://people.apache.org/~jacques/apache-drill-1.0.0-m1.rc4/ Please vote on this release - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
