[RESULT] [VOTE] [PROPOSAL] Validation incubator for JSR-303 Bean Validation
The vote passes with the following +1 votes: Craig Russell, Alan Cabrera, Luciano Resende, Matthias Wessendorf, Jean-Frederic Clere, Martijn Dashorst, Mark Struberg, Kevan Miller, James Carman, Niall Pemberton, Bill Stoddard Voting 0 or no vote specified: Nick Kew (recended his initial -1 vote on the name) There were no standing -1 votes. Non-binding +1 votes: Francis De Brabandere, Mohammad Nour El-Din, Gurkan Erdogdu The requested resources in the proposal have been updated to use "BVAL" to better reflect the project's intention and I'll attach the results email to the proposal for history. Thanks, Donald Woods On 2/23/10 10:57 AM, Donald Woods wrote: > Given the lack of response on the proposal and the push from our > champion to get moving :-), I'll assume lazy consensus and call a vote. > > I would like to present for a vote the following proposal to be > sponsored by the Incubator PMC for a new Validation podling. The goal > is to build a community around delivering a JSR-303 Bean Validation > implementation based on a new incoming codebase from Agimatec GmbH. > > The proposal is available on the wiki at and included below: > >http://wiki.apache.org/incubator/ValidationProposal > > > [] +1 to accept Validation into the Incubator > [] 0 don't care > [] -1 object and reason why. > > > Thanks, > Donald Woods > > > Proposal text from the wiki > > Validation > > Abstract > > The Validation project will deliver an implementation of the Bean > Validation Specification (JSR303) > > Proposal > > The initial Validation codebase will use the Agimatec Validation source, > which is an implementation of the Bean Validation Specification (JSR303). > > Although the destination of the Validation podling is not fixed, the > idea is that it will graduate to Apache Commons and replace the existing > Validator 1.x component as a new 2.0 codebase. > > Background > > Agimatec Validation has been developed by Agimatec Gmbh and is about 90% > complete towards implementing the JSR303 specification. The > Agimatec-Validation project is currently hosted on Google Code and is > ASL 2.0 licensed. Agimatec has no intention to complete or maintain the > implementation but has given the lead developer permission to continue > working on the project on his own time. > > A number of existing Apache projects (Geronimo, OpenJPA, MyFaces, > OpenEJB, Commons) are interested in an implementation of the Bean > Validation specification and Donald Woods suggested adopting the > Agimatec Validation code rather than starting from scratch. > > Rationale > > There is currently no Apache project focused on providing a JSR-303 > implementation. The existing Commons Validator 1.x project codebase does > not include support for Java 5 annotations and predates the JSR-303 > specification effort. By using the Agimatec-Validation code, we can > bootstrap the effort to create a Validator 2 release and focus on > polishing/enhancing the code, certification activities and integration > and support of other Apache projects. > > Current Status > > Agimatec Validation and is about 95% complete towards implementing the > JSR303 specification. > > An SGA for the Agimatec Validation has been received and on file from > Agimatec Gmbh. > > Meritocracy > > As a majority of the initial project members are existing ASF > committers, we recognize the desirability of running the project as a > meritocracy. We are eager to engage other members of the community and > operate to the standard of meritocracy that Apache emphasizes; we > believe this is the most effective method of growing our community and > enabling widespread adoption. > > Community > > Even though the reference implementation for the JSR-303 Bean Validation > specification is licensed under ASL 2.0, it is not being developed with > meritocracy in mind, as the release process is controlled by the JBoss > division of Red Hat to meet their own product needs. > > Validation aims to build a community of developers interested in the > definition and delivery of a JSR-303 compliant runtime, which can be > reused as a common component by a number of different projects (like > Geronimo, OpenJPA, MyFaces, ) By maintaining independence of the > target runtime, it is our intention to build the broadest possible > community of developers. > > Core Developers > > The lead developer from the Agimatec Validation project will be joined > by a number of committers from existing ASF projects. > > Alignment > > The purpose of Validation is to develop a certified implementation of > JSR-303. Some components may be developed and delivered by other Apache > projects, like: > > * Bean Validation 1.0 spec API - Apache Geronimo Specs subproject > * JSF2 integration - MyFaces ExtVal components > > Known Risks > > The current JSR-303 portions of the Agimatec-Validation code was > developed by a single developer from Agimatec (Roman) with no avail
Re: [VOTE] [PROPOSAL] Validation incubator for JSR-303 Bean Validation
Thanks Matthias and I've added you as a mentor. -Donald On 2/23/10 10:22 PM, Matthias Wessendorf wrote: > +1 to accept Validation into the Incubator > > afterwards we still can see where it actually ends up > > however I for sure want to see this at Apache. > > If you guys need a champion or mentor, count me in !! > > -M > > On Tue, Feb 23, 2010 at 11:45 PM, Donald Woods wrote: >> We're leaving the TLP/sub-project decision till graduation... >> >> -Donald >> >> >> On 2/23/10 5:36 PM, Brett Porter wrote: >>> As I understand it from the proposal, they intend to be Apache Commons >>> Validation. >>> >>> On 24/02/2010, at 4:19 AM, Nick Kew wrote: >>> On Tue, 23 Feb 2010 10:57:33 -0500 Donald Woods wrote: > Given the lack of response on the proposal and the push from our > champion to get moving :-), I'll assume lazy consensus and call a vote. > > I would like to present for a vote the following proposal to be > sponsored by the Incubator PMC for a new Validation podling. The goal > is to build a community around delivering a JSR-303 Bean Validation > implementation based on a new incoming codebase from Agimatec GmbH. > > The proposal is available on the wiki at and included below: > > http://wiki.apache.org/incubator/ValidationProposal -1 to a project that could end up being called "Apache Validation" or just "Validation". That's too big/general a word for a project name. No objection under a changed name. I'd suggest adding an adjective to indicate what is being validated. -- Nick Kew - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org >>> >>> -- >>> Brett Porter >>> br...@apache.org >>> http://brettporter.wordpress.com/ >>> >>> >>> >>> >>> >>> - >>> 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: [VOTE] Approve the release of apache-esme-1.0-RC1-incubating
+1 IPMC Binding. Nice job! Dan On Thu February 25 2010 11:42:55 pm Richard Hirsch wrote: > The ESME community has voted on and approved the release of > apache-esme-1.0-RC1-incubating. > We would now like to request the approval of the Incubator PMC for this > release. > > Details of the ESME community vote can be found here: > http://www.mail-archive.com/esme-...@incubator.apache.org/msg03120.html > > The candidate can be found at > > http://people.apache.org/~rhirsch/esme/ > > See the CHANGES.txt file for details on release contents. The release > candidate is a tar archive of the sources in > https://svn.apache.org/repos/asf/incubator/esme/tags/apache-esme-1.0-RC1-in > cubating/ > > The MD5 checksum of the apache-esme-1.0-RC1-incubating.src.tar.gz > release package is > 35 72 D0 B3 49 3C C3 BA D5 4F 57 E8 EA 1D 9D 54 > > Please vote on releasing this package as Apache ESME 1.0-incubating. > > Please vote to publish this release by Monday, March 1 05:41 CET, > please include the testing you performed to arrive at your vote > [ ] +1 Publish > [ ] 0 Abstain > [ ] -1 Don't publish, because... > > Below is a summary of the vote on the ESME mailing list. The link to > the vote result is here: > http://www.mail-archive.com/esme-...@incubator.apache.org/msg03156.html > > Thanks > > Dick > > > > > > Hello All, > > Voting on the ESME apache-esme-1.0-RC1-incubating has concluded > > Results: > > 5 binding +1 vote > > Dick Hirsch +1 > Ethan Jewett +1 > Anne Kathrine Petteroe +1 > Gianugo Rabellino +1 > Bertrand Delacretaz +1 > > 2 non-binding +1 votes > > Daniel Koller +1 > Uday Subbarayan +1 > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Chatterbot, a lightweight framework for chat responders
Ignite lists Smack as licensed under the Apache license v2 (http://www.apache.org/licenses/LICENSE-2.0), though it's not an Apache project. I assume that license is revokable by Ignite at any time? How does incorporating outside code work in Apache projects? Don On Mon, Mar 1, 2010 at 6:43 PM, Donald Whytock wrote: > Well, it seemed presumptuous to ask about mentors when I hardly had a > community...but thank you for your consideration. Yes, mentoring > would be appreciated. > > I tested my XMPP handler against two servers: Google's chat server and > one managed by dreamhost.com. The handler is rudimentary, yes; there > are several functions of the protocol it doesn't handle yet. A big > one is dynamically accepting/rejecting users; at the moment I manually > authenticate new contacts. > > But it does work (mixed results with Google). V0.3 will make a > connection to its server, accept messages from authenticated contacts > and send responses. With the right Parsers it should communicate with > multiple users, relaying messages between them and originating > messages based on other users' actions. I have Parsers that did this > for v0.2 that I haven't ported over yet. > > The handler was a first effort for me, meant as an education in > protocol handling. Happy to look at other things now...Thanks, I'll > check out Smack. (http://www.igniterealtime.org/projects/smack/) > > Don > > On Mon, Mar 1, 2010 at 11:42 AM, Bernd Fondermann > wrote: >> Hi, >> >> What about mentors? I cannot find any note you are actively searching >> for them, but maybe I missed that. >> >> As I think about volunteering to mentor, my question is: Against what >> server did you test your own XMPP implementation? Does it really work >> as it seems to be rudimentary to me. Why didn't you use a XMPP client >> lib like Smack? >> >> Thanks, >> >> Bernd >> >> On Mon, Mar 1, 2010 at 12:54, Donald Whytock wrote: >>> Hello again... >>> >>> Following is the revised proposal text, as posted on the wiki. >>> Significant changes are the goals, which now focus on building the >>> framework around Felix and devising a standard for protocol handlers >>> to be used both inside and outside the project, and the committer >>> list, which now includes Christopher Brind. The wiki copy is at >>> >>> http://wiki.apache.org/incubator/ChatterbotProposal >>> >>> Thanks... >>> >>> Don >>> >>> - >>> >>> Proposal: >>> >>> Abstract >>> >>> ChatterBot is a lightweight, multiprotocol framework and container for >>> chat responders. >>> >>> Proposal >>> >>> ChatterBot is a framework for developing chat responders (applications >>> that respond to messages received via online chat) and a container for >>> deploying them. It is written in Java SE, and runs as a Java >>> application. Chat responders are built by extending a single class >>> and modifying a configuration file to reference the new class. >>> ChatterBot's focus is on the following characteristics: >>> >>> * Small: The current framework consists of eight core classes. >>> * Standalone: ChatterBot does not require external servers to operate. >>> * Portable: ChatterBot should work as run from any Java-capable >>> machine. For full functionality that machine should have internet >>> access, but localhost and console connectivity are possible. It >>> should be possible to run multiple instances of ChatterBot on the same >>> machine or on separate machines with no loss of functionality. >>> * Extensible: An instance of ChatterBot can support multiple message >>> parsers and protocols. Adding more is done by editing a configuration >>> file. >>> * Dynamic: Activating and de-activating modules should be possible >>> during runtime. >>> * Multi-user access: Multiple users, over multiple protocols, should >>> be able to access deployed applications. >>> >>> Rationale >>> >>> A chat responder can serve as a user interface to applications, either >>> those built into the responder or external applications with which the >>> responder communicates. Such an interface is more secure than >>> interfaces such as Telnet or web services since it does not require >>> open ports in the firewall; the container connects out through the >>> firewall to the chat server, rather than allowing users to connect in. >>> >>> A lightweight chat responder can be installed on any system to allow >>> command-line access to users over whatever protocol a user may have >>> access to. Thus applications can be accessed from web interfaces, >>> instant-message systems, text messages, email, etc. A scalable >>> container can allow as many or as few access protocols as are desired. >>> >>> ChatterBot, therefore, has value for those circumstances where a user >>> interface is needed but a server-based or enterprise solution is >>> either not possible or not desired. It also can serve as a bridge >>> between applications, where one or more uses a chat protocol such as >>> XMPP to communicate. >>> >>> Background >>>
Re: [PROPOSAL] Chatterbot, a lightweight framework for chat responders
Well, it seemed presumptuous to ask about mentors when I hardly had a community...but thank you for your consideration. Yes, mentoring would be appreciated. I tested my XMPP handler against two servers: Google's chat server and one managed by dreamhost.com. The handler is rudimentary, yes; there are several functions of the protocol it doesn't handle yet. A big one is dynamically accepting/rejecting users; at the moment I manually authenticate new contacts. But it does work (mixed results with Google). V0.3 will make a connection to its server, accept messages from authenticated contacts and send responses. With the right Parsers it should communicate with multiple users, relaying messages between them and originating messages based on other users' actions. I have Parsers that did this for v0.2 that I haven't ported over yet. The handler was a first effort for me, meant as an education in protocol handling. Happy to look at other things now...Thanks, I'll check out Smack. (http://www.igniterealtime.org/projects/smack/) Don On Mon, Mar 1, 2010 at 11:42 AM, Bernd Fondermann wrote: > Hi, > > What about mentors? I cannot find any note you are actively searching > for them, but maybe I missed that. > > As I think about volunteering to mentor, my question is: Against what > server did you test your own XMPP implementation? Does it really work > as it seems to be rudimentary to me. Why didn't you use a XMPP client > lib like Smack? > > Thanks, > > Bernd > > On Mon, Mar 1, 2010 at 12:54, Donald Whytock wrote: >> Hello again... >> >> Following is the revised proposal text, as posted on the wiki. >> Significant changes are the goals, which now focus on building the >> framework around Felix and devising a standard for protocol handlers >> to be used both inside and outside the project, and the committer >> list, which now includes Christopher Brind. The wiki copy is at >> >> http://wiki.apache.org/incubator/ChatterbotProposal >> >> Thanks... >> >> Don >> >> - >> >> Proposal: >> >> Abstract >> >> ChatterBot is a lightweight, multiprotocol framework and container for >> chat responders. >> >> Proposal >> >> ChatterBot is a framework for developing chat responders (applications >> that respond to messages received via online chat) and a container for >> deploying them. It is written in Java SE, and runs as a Java >> application. Chat responders are built by extending a single class >> and modifying a configuration file to reference the new class. >> ChatterBot's focus is on the following characteristics: >> >> * Small: The current framework consists of eight core classes. >> * Standalone: ChatterBot does not require external servers to operate. >> * Portable: ChatterBot should work as run from any Java-capable >> machine. For full functionality that machine should have internet >> access, but localhost and console connectivity are possible. It >> should be possible to run multiple instances of ChatterBot on the same >> machine or on separate machines with no loss of functionality. >> * Extensible: An instance of ChatterBot can support multiple message >> parsers and protocols. Adding more is done by editing a configuration >> file. >> * Dynamic: Activating and de-activating modules should be possible >> during runtime. >> * Multi-user access: Multiple users, over multiple protocols, should >> be able to access deployed applications. >> >> Rationale >> >> A chat responder can serve as a user interface to applications, either >> those built into the responder or external applications with which the >> responder communicates. Such an interface is more secure than >> interfaces such as Telnet or web services since it does not require >> open ports in the firewall; the container connects out through the >> firewall to the chat server, rather than allowing users to connect in. >> >> A lightweight chat responder can be installed on any system to allow >> command-line access to users over whatever protocol a user may have >> access to. Thus applications can be accessed from web interfaces, >> instant-message systems, text messages, email, etc. A scalable >> container can allow as many or as few access protocols as are desired. >> >> ChatterBot, therefore, has value for those circumstances where a user >> interface is needed but a server-based or enterprise solution is >> either not possible or not desired. It also can serve as a bridge >> between applications, where one or more uses a chat protocol such as >> XMPP to communicate. >> >> Background >> >> ChatterBot began in 2005 as a thin-server approach to online >> multi-user board games, implemented as applets sending gamestate >> changes to one another via message relaying. The idea was to make as >> general-purpose a server as possible, so that multiple games could be >> built that employed the same message-relaying system. >> >> Version 0.2 of the server was then refined in 2008 to allow for more >> varied and functional message-handlers
Re: [PROPOSAL] Chatterbot, a lightweight framework for chat responders
Hi, What about mentors? I cannot find any note you are actively searching for them, but maybe I missed that. As I think about volunteering to mentor, my question is: Against what server did you test your own XMPP implementation? Does it really work as it seems to be rudimentary to me. Why didn't you use a XMPP client lib like Smack? Thanks, Bernd On Mon, Mar 1, 2010 at 12:54, Donald Whytock wrote: > Hello again... > > Following is the revised proposal text, as posted on the wiki. > Significant changes are the goals, which now focus on building the > framework around Felix and devising a standard for protocol handlers > to be used both inside and outside the project, and the committer > list, which now includes Christopher Brind. The wiki copy is at > > http://wiki.apache.org/incubator/ChatterbotProposal > > Thanks... > > Don > > - > > Proposal: > > Abstract > > ChatterBot is a lightweight, multiprotocol framework and container for > chat responders. > > Proposal > > ChatterBot is a framework for developing chat responders (applications > that respond to messages received via online chat) and a container for > deploying them. It is written in Java SE, and runs as a Java > application. Chat responders are built by extending a single class > and modifying a configuration file to reference the new class. > ChatterBot's focus is on the following characteristics: > > * Small: The current framework consists of eight core classes. > * Standalone: ChatterBot does not require external servers to operate. > * Portable: ChatterBot should work as run from any Java-capable > machine. For full functionality that machine should have internet > access, but localhost and console connectivity are possible. It > should be possible to run multiple instances of ChatterBot on the same > machine or on separate machines with no loss of functionality. > * Extensible: An instance of ChatterBot can support multiple message > parsers and protocols. Adding more is done by editing a configuration > file. > * Dynamic: Activating and de-activating modules should be possible > during runtime. > * Multi-user access: Multiple users, over multiple protocols, should > be able to access deployed applications. > > Rationale > > A chat responder can serve as a user interface to applications, either > those built into the responder or external applications with which the > responder communicates. Such an interface is more secure than > interfaces such as Telnet or web services since it does not require > open ports in the firewall; the container connects out through the > firewall to the chat server, rather than allowing users to connect in. > > A lightweight chat responder can be installed on any system to allow > command-line access to users over whatever protocol a user may have > access to. Thus applications can be accessed from web interfaces, > instant-message systems, text messages, email, etc. A scalable > container can allow as many or as few access protocols as are desired. > > ChatterBot, therefore, has value for those circumstances where a user > interface is needed but a server-based or enterprise solution is > either not possible or not desired. It also can serve as a bridge > between applications, where one or more uses a chat protocol such as > XMPP to communicate. > > Background > > ChatterBot began in 2005 as a thin-server approach to online > multi-user board games, implemented as applets sending gamestate > changes to one another via message relaying. The idea was to make as > general-purpose a server as possible, so that multiple games could be > built that employed the same message-relaying system. > > Version 0.2 of the server was then refined in 2008 to allow for more > varied and functional message-handlers, and was used to implement a > room system that allowed for room-specific applications -- parsers > that checked the user's room before handling a command and sent > responses to other room occupants. This version was structured > entirely around XMPP. The global namespace was introduced to allow > modules to communicate with relatively limited coupling. > > Version, 0.3, as of late 2009, functions with XMPP and has the > capacity to function with whatever other protocols channels are coded > for. V0.3, though, uses a custom shell, with rudimentary module > lifecycle capability. > > This proposal introduces version 0.4, to be based on OSGi for module > lifecycle management and event-driven module synchronization. > Applications originally built for v0.2 will be ported to v0.4. > > Current Status > > Meritocracy: > > Peer review and alternate ideas are welcomed in this project with open > arms. This project was intended specifically as an alternative to > traditional server-based or enterprise architecture; however, it is > recognized that tried-and-tested principles established in enterprise > architecture may be applicable here. > > Core Developers: > > As of late 2009, there is one dev
Re: [PROPOSAL] Chatterbot, a lightweight framework for chat responders
Hello again... Following is the revised proposal text, as posted on the wiki. Significant changes are the goals, which now focus on building the framework around Felix and devising a standard for protocol handlers to be used both inside and outside the project, and the committer list, which now includes Christopher Brind. The wiki copy is at http://wiki.apache.org/incubator/ChatterbotProposal Thanks... Don - Proposal: Abstract ChatterBot is a lightweight, multiprotocol framework and container for chat responders. Proposal ChatterBot is a framework for developing chat responders (applications that respond to messages received via online chat) and a container for deploying them. It is written in Java SE, and runs as a Java application. Chat responders are built by extending a single class and modifying a configuration file to reference the new class. ChatterBot's focus is on the following characteristics: * Small: The current framework consists of eight core classes. * Standalone: ChatterBot does not require external servers to operate. * Portable: ChatterBot should work as run from any Java-capable machine. For full functionality that machine should have internet access, but localhost and console connectivity are possible. It should be possible to run multiple instances of ChatterBot on the same machine or on separate machines with no loss of functionality. * Extensible: An instance of ChatterBot can support multiple message parsers and protocols. Adding more is done by editing a configuration file. * Dynamic: Activating and de-activating modules should be possible during runtime. * Multi-user access: Multiple users, over multiple protocols, should be able to access deployed applications. Rationale A chat responder can serve as a user interface to applications, either those built into the responder or external applications with which the responder communicates. Such an interface is more secure than interfaces such as Telnet or web services since it does not require open ports in the firewall; the container connects out through the firewall to the chat server, rather than allowing users to connect in. A lightweight chat responder can be installed on any system to allow command-line access to users over whatever protocol a user may have access to. Thus applications can be accessed from web interfaces, instant-message systems, text messages, email, etc. A scalable container can allow as many or as few access protocols as are desired. ChatterBot, therefore, has value for those circumstances where a user interface is needed but a server-based or enterprise solution is either not possible or not desired. It also can serve as a bridge between applications, where one or more uses a chat protocol such as XMPP to communicate. Background ChatterBot began in 2005 as a thin-server approach to online multi-user board games, implemented as applets sending gamestate changes to one another via message relaying. The idea was to make as general-purpose a server as possible, so that multiple games could be built that employed the same message-relaying system. Version 0.2 of the server was then refined in 2008 to allow for more varied and functional message-handlers, and was used to implement a room system that allowed for room-specific applications -- parsers that checked the user's room before handling a command and sent responses to other room occupants. This version was structured entirely around XMPP. The global namespace was introduced to allow modules to communicate with relatively limited coupling. Version, 0.3, as of late 2009, functions with XMPP and has the capacity to function with whatever other protocols channels are coded for. V0.3, though, uses a custom shell, with rudimentary module lifecycle capability. This proposal introduces version 0.4, to be based on OSGi for module lifecycle management and event-driven module synchronization. Applications originally built for v0.2 will be ported to v0.4. Current Status Meritocracy: Peer review and alternate ideas are welcomed in this project with open arms. This project was intended specifically as an alternative to traditional server-based or enterprise architecture; however, it is recognized that tried-and-tested principles established in enterprise architecture may be applicable here. Core Developers: As of late 2009, there is one developer, Donald Whytock (dwhytock at gmail dot com). Donald Whytock has several years of experience as a software developer, working in a variety of languages, including C, Java, Perl, PHP, JavaScript and SQL. He develops both professionally and casually; ChatterBot has been an independent, voluntary effort. Alignment: ChatterBot's primary potential alignment with ASF is that of a framework for internet-accessible applications. As command parsers can be built to interface with other applications, ChatterBot can be employed as a general-purpose remote console operating over instant mess
Re: [VOTE] Approve the release of apache-esme-1.0-RC1-incubating
Bertrand Delacretaz wrote: On Fri, Feb 26, 2010 at 9:35 AM, Gianugo Rabellino wrote: On Fri, Feb 26, 2010 at 5:42 AM, Richard Hirsch wrote: The ESME community has voted on and approved the release of apache-esme-1.0-RC1-incubating. We would now like to request the approval of the Incubator PMC for this release. Let me restate my +1 (IPMC hat) here. Me too, +1 which makes two mentors/IPMC members binding votes. An and additional +1! Sylvain -- Sylvain Wallez - http://bluxte.net - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
