Re: Subversion is now an official ASF project!
Perhaps we should change the logo on the top right of http://subversion.apache.org. It still says incubator. On Thu, Feb 18, 2010 at 9:06 AM, Julian Foad julian.f...@wandisco.com wrote: Hooray! Many thanks to you and the other people who each put in a lot of work to make this happen. - Julian Greg Stein wrote: The ASF Board just voted to approve the graduation of Subversion from the Incubator. We are now an official project of the Apache Software Foundation! Go forth! Be merry! - 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] [PROPOSAL] Validation incubator for JSR-303 Bean Validation
We already have Apache Commons Validator. Why not just bring this code into that project? On Tue, Feb 23, 2010 at 5:36 PM, Brett Porter br...@apache.org 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 dwo...@apache.org 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
Re: [VOTE] [PROPOSAL] Validation incubator for JSR-303 Bean Validation
Sorry, didn't read the proposal very closely. The idea was that it would be brought into Commons Validator and become the 2.x codebase. I like that idea and I would think it would be wise to go through the incubator to make sure the codebase is donated cleanly to the ASF. My point was mainly about the name. If it takes over the Commons Validator project, then we already have a name. Issue closed. Right? On Wed, Feb 24, 2010 at 8:49 AM, Kevan Miller kevan.mil...@gmail.com wrote: On Feb 24, 2010, at 8:18 AM, James Carman wrote: We already have Apache Commons Validator. Why not just bring this code into that project? Heh. That's been pretty well discussed, already, by both Commons and Incubator. You can scan the logs for details. The subject was [PROPOSAL] Validation incubator for JSR-303 Bean Validation. I think the following sums up where we landed on that issue (at least it pretty well sums up where I landed on the issue): On Jan 18, 2010, at 9:55 PM, Noel J. Bergman wrote: Kevan Miller wrote: I think we'd agree that a fair amount of community building will be required for this new codebase and group of committers. [However,] given the small makeup of the Commons Validator community, I don't think it's reasonable to expect the Commons community to do this community building. That seems a cogent enough explanation to warrant Incubation. Thank you. I also believe that when you talk about multiple projects collaborating actively on a shared, but separately useable, codebase, a TLP is often justified. --kevan - 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] [PROPOSAL] Validation incubator for JSR-303 Bean Validation
On Wed, Feb 24, 2010 at 9:11 AM, Kevan Miller kevan.mil...@gmail.com wrote: Yes. That's how I view it. It's more than code clearance, however. There are processes for that, already. Community building is why it is starting off as an Incubator project. I think graduating to become Commons Validator v2 is a great outcome. But that's something for the new community to decide. With the names on the proposal already interested, it would seem that there's already a community (definitely enough for a Commons project). Heck, I'm the only one who has ever worked on Commons Proxy. The folks who are ASF committers already and they're not Commons committers could become Commons committers pretty easily I'd guess. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] [PROPOSAL] Validation incubator for JSR-303 Bean Validation
The proposal says that this will take over for Commons Validator. Why are we still discussing names? We already have one, Commons Validator. On Thu, Feb 25, 2010 at 9:06 AM, Gurkan Erdogdu cgurkanerdo...@gmail.com wrote: +1 (non-binding). OpenBeanValidation as a name will be cool :) Thanks; --Gurkan 2010/2/23 Donald Woods dwo...@apache.org 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 available documents on the structure of the code. Orphaned Products The project will be implementing the JSR-303 Bean Validation specification, which is a required component for both the Web and Full profiles of Java EE 6. There is minimal risk of this work becoming non-strategic and the contributors are confident that a larger community will form within the project in a relatively short space of time. Inexperience with Open Source Many of the committers have
Re: Anyone using ASF software in bio-informatics?
My client is using a variety of Apache projects in their bio-informatics work. We're using Wicket, a lot of the Commons stuff (VFS is a *big* one), Lucene, HttpClient, Subversion, Velocity, etc. We looked into using Hadoop, but decided to go with Mallet instead. Hadoop was a little overly-complicated for our needs. On Wed, Mar 10, 2010 at 11:51 AM, Grant Ingersoll gsing...@apache.org wrote: For starters: Lucene: http://gmod.org/wiki/Lucegene/ I also know of several big Pharma companies using it, but can't say names. You can likely guess, as they are instantly recognizable global brands. TREC Genomics focused on info retrieval on genome data. Lucene is used by NIST to setup the relevance pool, etc. I know many people that use it to search PubMed and the like and then correlate it with outputs from internal documents/experiments/etc. Hadoop One I saw: http://www.slideshare.net/cloudera/hw09-hadoop-for-bioinfomatics I'm sure others in the Hadoop community can name some more. I recall seeing some others go by my radar, but don't see URLs. These days, when your talking TBs of data for a single sequencing run (or others), you need large scale data crunching capabilities Mahout I'd ask on mahout-u...@lucene.a.o. Nothing comes to mind, but we have a lot of lurkers there, so it might hit home. Mahout is a very likely candidate for this kind of work. Some basic searching for Lucene genetics, etc. will lead you to a good deal of results. HTH, Grant On Mar 10, 2010, at 10:35 AM, Mattmann, Chris A (388J) wrote: Hey Grant, Here here on that. Some of the same systems we use OODT on use Lucene as well, I'd be happy to provide some feedback, let me know. Cheers, Chris On 3/10/10 7:18 AM, Grant Ingersoll gsing...@apache.org wrote: Lucene is used in a number of places for bio-informatics. Hadoop as well and I've heard rumors of Mahout as well. I can send pointers here or offline and also have some contacts if you'd like. -Grant On Mar 10, 2010, at 4:55 AM, Ross Gardler wrote: I've been invited to keynote at the Open bio-informatics conference in July, wearing my ASF hat. their invite said: Is anyone here using ASF software in this space? Ross - 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: Apache Isis: project pre-proposal: looking for mentors and a sponsor
More precisely, that'd be James Carman (Commons). I'm not on the Wicket team. On Wed, Jul 21, 2010 at 5:56 AM, Dan Haywood dkhayw...@gmail.com wrote: We're considering proposing a group of related open source projects to the Apache Incubator. At an unconference a few weekends ago I met and sounded out Bertrand Delacrataz and Lars Eilebrecht, who suggested a brief posting here would be a good first step. So: the Apache Isis (?) project will provide the ability to rapidly develop domain-driven applications. Built on the Naked Objects framework (http://nakedobjects.org) and a number of related sister projects (http://starobjects.org), it allows full stack apps to be built just by writing pojo domain objects. Technically, it's somewhat akin to an ORM, but rather than just automatically persisting your objects, it automatically provides all the other necessary layers. This means that the development goes very very quickly, focusing on the bit that really matters; the business application. One particularly important aspect is the ability to customise the generated UIs. The framework supports pluggable viewers running either as webapps and RIA, and uses existing libraries such as Apache Wicket to support customisation. The framework as a whole is customisable and provides a plugin architecture to allow the other components to be pluggable. For some time Naked Objects, the framework, has elicited interest from early adopters, but our community remains small. We're hoping that Apache will provide a platform by which we can grow our community into the early majority. We can demonstrate the commitment to do this (two books have been written on Naked Objects). Until recently there were just two main committers, both freelancer developers based in the UK. Since then we have picked up three new committers (in Sweden, USA and South Africa), two directly attributable to the publication of the second of these books in Dec 2009. From our understanding of the Apache process, our proposal will need some mentors and a sponsor. Vincent Massol (Maven) has already offered, as has James Carman (Wicket). We're hoping that this post might interest a few more, in which case we'll post a formal project proposal. Thanks for reading this, looking forward to your replies. Dan Haywood Robert Matthews - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: ISIS vote result
For those of us who haven't mentored before, it might be good to give us a chance to do some of these things On Sep 7, 2010 7:49 AM, Benson Margulies bimargul...@gmail.com wrote: I just created the first JIRA for ISIS infrastructure, but I have this sinking feeling that I've gotten ahead of myself. Should I have waited for Noel to formally announce the vote results, or does Dan's email do the job?
Re: No dev-, user- lists for small podlings (was: Re: [PROPOSAL] Kitty to Enter the Incubator)
Isn't Isis a different bird though? It has been around for a long time and is likely to actually have existing users On Sep 8, 2010 7:04 AM, Benson Margulies bimargul...@gmail.com wrote: Well, we could neglect to tell anyone about the user list until we need it. On Wed, Sep 8, 2010 at 3:16 AM, Dan Haywood dkhayw...@gmail.com wrote: Isis mentors: Given we're in the same situation and are still being bootstrapped, should we follow this advice, ie start off with a combined mailing list for -dev and -user? Dan On 08/09/2010 08:10, Martijn Dashorst wrote: On Wed, Sep 8, 2010 at 7:22 AM, Greg Steingst...@gmail.com wrote: On Tue, Sep 7, 2010 at 20:29, Matthew Sacksmatt...@matthewsacks.com wrote: ... *Mailing Lists* kitty-dev kitty-commits kitty-user Is there a large user community already? If not, then splitting the community across dev/user does not make sense. You want to keep the users and developers on the same mailing list until one starts to overwhelm the other. By partitioning the lists too early, you risk never reaching critical mass on *either* mailing list. This is actually great advice, and I wish we'd done this with a couple of podlings that are currently too small to graduate. In retrospect empire-db and etch really could have done without the user- list IMO. Martijn - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: No dev-, user- lists for small podlings (was: Re: [PROPOSAL] Kitty to Enter the Incubator)
On Wed, Sep 8, 2010 at 7:39 AM, dan haywood d...@haywood-associates.co.uk wrote: For the moment at least the dev community is more active (or at least more vocal), so their mailing list should be the main focal point. As I said in the other email, when we have more user traffic than dev traffic, then we can vote to split them out. Why are we even having this discussion? When did mailing lists become such a heavyweight operation that we have to discuss at length whether they should even exist? Just create the user/dev/commits/issues lists and be done with it. If nobody uses the user list, so be it. I think it's just more confusing to start moving traffic from one list to another. Keep things consistent. And another benefit of putting user traffic on the dev list is that it'll give the devs exposure to any probs that regular users are having with actually using the framework (ie so we can mature its documentation etc) The developers should be listening to the user list so that they can answer questions. They can't just hide in the dev list and not listen to the community. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Change name of Lucene Connectors Framework to Apache Connectors Framework
I'm -1 (don't know if it's binding or not. I requested to join the PMC, but didn't hear anything back). I think the name is too general. Why not just choose some animal name or something like everyone else is doing? On Wed, Sep 8, 2010 at 8:18 AM, Grant Ingersoll gsing...@apache.org wrote: Hi, After much debate both here and on the connectors mailing list, the LCF community has voted (see http://mail-archives.apache.org/mod_mbox/incubator-connectors-dev/201008.mbox/browser) and would like to officially change our name to be the Apache Connectors Framework. We would like the Incubator PMC to vote to make this official. [] +1 Change the Lucene Connector Framework to the Apache Connector Framework [] 0 Don't care [] -1 Don't change it Since this is a procedural vote (http://www.apache.org/foundation/voting.html), it is a majority rule vote with binding votes coming from IPMC members. The vote is open for 72 hours. Here's my +1 (binding). Thanks, Grant - 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: Role of Incubator PMC Votes
name=trademark On Thu, Sep 9, 2010 at 8:30 AM, Tim Williams william...@gmail.com wrote: I'm watching the renaming vote thread and I find it odd that folks are -1-ing the project's vote. I've read the role of the IPMC[1] and the policy[2] and can't find the basis for our (IPMC) doing anything other than ack-ing they're vote. It seems like votes from the IPMC should only be relevant/binding when the matter in question is release/legal/trademark/etc-type issues that could [legally] effect the foundation. I dunno, this seems purely a project matter to me (like a logo, code, etc.) - second-guessing a project team on these sort of subjective things seems counter-productive to grooming self-sustaining projects to me. So, is this normal - why does the IPMC really get anything more than an advising role in these sorts of matters (and why is that healthy)? Thanks, --tim [1] - http://incubator.apache.org/incubation/Roles_and_Responsibilities.html#Incubator+Project+Management+Committee+%28PMC%29 [2] - http://incubator.apache.org/incubation/Incubation_Policy.html#Incubation+Policy - 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: Role of Incubator PMC Votes
On Thu, Sep 9, 2010 at 8:38 AM, Tim Williams william...@gmail.com wrote: Are you suggesting there are trademark concerns with the name the project has chosen? If so, then yes, that's a valid reason for the IPMC to challenge a project's vote - as a part of 'grooming' them to think through these things... in other words, the basis for us challenging the vote is trademark concern rather than I don't like that name, it's too broad... ... but I haven't seen a mark concern brought up... No, you were saying that the IPMC has no say in this naming matter and that they should only be concerned with release/legal/trademark/etc-type issues. My point is that the name is the trademark. So, that would fall under the IPMC's jurisdiction. That's all I was saying. As far as there being a trademark issue with the name, I would think it would be pretty hard to go after someone for using the term connectors framework. That's way too general. I don't really think there's a mark concern, per se. I voiced my opinion because the person opened up the vote and said only IPMC members have a binding vote. As someone pointed out before, it's eventually up to the board to decide if the project makes it out of the incubator with that name. If there are a lot of folks on the IPMC that think the name stinks, then it's a fair chance that there will be some on the board who think it stinks too. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Role of Incubator PMC Votes
On Thu, Sep 9, 2010 at 1:51 PM, Greg Stein gst...@gmail.com wrote: I haven't followed this particular issue because it seems like a slamdunk easy thing. If the podling wants to change their name, then fine. Sounds easy enough. I would see no reason for anybody outside the podling to -1 that choice, and might even say that I'd be upset if they did... They asked. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Role of Incubator PMC Votes
On Thu, Sep 9, 2010 at 3:13 PM, Greg Stein gst...@gmail.com wrote: As I said, I haven't followed it. I meant if the -1 was a veto. If the IPMC was vetoing a podling's choices on stuff like this. If you're only using a vote as a preference/opinion marker, then sure... definitely no problems with that! The vote was stated to be a majority-rules vote, so my -1 was merely an indication of my opinion about the name. I normally wouldn't get into the podling's business (I don't troll their lists), but they did ask for the votes on the general list. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Role of Incubator PMC Votes
For this type of vote, my -1 just means I'm against. It's not a veto. On Fri, Sep 10, 2010 at 6:04 AM, Mark Struberg strub...@yahoo.de wrote: James can I interpret your statement that this would rather be a -0 or -0.1? Stating that there is no veto but that you personally don't like it ;) LieGrue, strub --- On Thu, 9/9/10, James Carman ja...@carmanconsulting.com wrote: From: James Carman ja...@carmanconsulting.com Subject: Re: Role of Incubator PMC Votes To: general@incubator.apache.org Date: Thursday, September 9, 2010, 7:17 PM On Thu, Sep 9, 2010 at 3:13 PM, Greg Stein gst...@gmail.com wrote: As I said, I haven't followed it. I meant if the -1 was a veto. If the IPMC was vetoing a podling's choices on stuff like this. If you're only using a vote as a preference/opinion marker, then sure... definitely no problems with that! The vote was stated to be a majority-rules vote, so my -1 was merely an indication of my opinion about the name. I normally wouldn't get into the podling's business (I don't troll their lists), but they did ask for the votes on the general list. - 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: Role of Incubator PMC Votes
On Fri, Sep 10, 2010 at 6:32 AM, Tim Williams william...@gmail.com wrote: That vote is majority rules, so the IPMC could in effect overrule the project - the preference/opinion had already previously been gathered. In any case, I was using that instance to ask the broader question of why we (IPMC) get binding votes on project matters. It seems to me that the healthy thing to do is closer to the board model where we trust projects to do the right thing, ask for an ack, and then only challenge the project on the basis of a legal/release/trademark/etc issue. If we tell the projects that you have to re-vote with the peanut gallery, then the peanut gallery effect is predictable. Those votes, for example, are because they don't *like* the new name personally, not because there's any real problems with it. Nobody told them to re-vote in this situation. They took it upon themselves to ask the IPMC. If you ask for opinions from people, you're going to get them. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Role of Incubator PMC Votes
On Fri, Sep 10, 2010 at 8:34 AM, Mark Miller markrmil...@gmail.com wrote: To be clear, we where asking for a [VOTE] and not a [DISCUSS] - we wanted the vote to ratify our own vote on the subject. There was already a long discussion on general and the connectors mailing list - tons of discussion actually. At this point, we have taken that discussion into consideration and ran a vote. We are now not seeking opinions about how the results of our vote sucks in someones personal opinion - but a vote on whether the name chosen by the community can go forward. Take that for what it's worth - but we already collected many opinions over a couple weeks I think. If that's the case, then I have no objection to you guys (the PPMC) deciding on your own. I have no objection to the name change. It just appeared as though you were asking for our opinion on the name. I think you could have just asked for an acknowledgment from IPMC about the name change. That probably would have sufficed in this case. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Java package names
On Tue, Oct 12, 2010 at 4:28 PM, Benson Margulies bimargul...@gmail.com wrote: From the mentor standpoint, what's important to me is that there is no ASF requirement to change those packages. The community can decide to do it sooner, later, or not at all. The community can decide to make a slew of compatibility wrappers. The community, most importantly, can push toward a release with whatever naming it can reach a consensus on. I would think that it would be considered tacky for us to publish classes in the com.sun.* packages. It's a bit misleading, IMHO. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Boot strapping Android projects @ Apache
+1, I bought an Android development book a while back, but haven't had the opportunity to do any real Android development. I'd be interested in seeing what others are up to. On Tue, Nov 9, 2010 at 10:13 AM, Noel J. Bergman n...@devtech.com wrote: About a half dozen or so of us met up at ApacheCon after the lightning talks to talk briefly about Android @ the ASF. The proposal is to create an android-inter...@i.a.o (we also thought about @labs, but the general consenus seemed to be the Incubator due to some of the Labs' restrictions, which we think are good restrictions). We want to encourage others working on Android-related code to share experience and existence with their fellow Committers. For example, did you know that Felix Aries already work with Android? What else does? What else should? Etc. In other words, we want to provide a gathering point for all of the people working in isolation -- to provide a meeting place for those intersted in expanding Android-based activity at the ASF. It is not so much an umbrella as a vital nexus, and breeding ground for importing or creating projects, which would then stand on their own. --- Noel - 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: Conference call
On Fri, Nov 19, 2010 at 2:20 PM, Bertrand Delacretaz bdelacre...@apache.org wrote: So Skype calls are fine (and I like Craig's list of criteria for them), but as far as the ASF is concerned they don't count - anything important has to happen on list. Audio transcripts are useless IMO. Right, the key criteria (IMHO) is the no decisions are made criteria. We don't want/need factions of people getting together off-list which will guide the project. The user community needs to have the opportunity to be involved in the discussions. The reason I objected was that the suggestion was made that we set up a regularly-scheduled skype call for this stuff. Not a good idea. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: Why am I getting those emails? (was: FW: MODERATE for lucene-net-user@incubator.apache.org)
Aren't those emails supposed to be sent to the moderators of the list, not to just anyone subscribed to it? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Sunday, April 23, 2006 9:28 PM To: general@incubator.apache.org Subject: Re: Why am I getting those emails? (was: FW: MODERATE for lucene-net-user@incubator.apache.org) Hi George, Try reply all which sends the message to accept plus approve. One is for this single message; the other is a permanent allow. Craig On Apr 23, 2006, at 6:09 PM, George Aroush wrote: Hi folks, Even though I have subscribed to Lucene.Net mailing list, when I submit an email to lucene-net-user@incubator.apache.org I am still getting an email like the one below and it won't appear on the Lucene.Net mailing list until when I approve it. How come? Regards, -- George -Original Message- From: lucene-net-user- [EMAIL PROTECTED] e.org [mailto:lucene-net-user- [EMAIL PROTECTED] or.apache.org] Sent: Sunday, April 23, 2006 9:05 PM To: Recipient list not shown: Cc: lucene-net-user-allow-tc.1145840723.ijpagebdfkdiippacacc- [EMAIL PROTECTED] ncubator.apache.org Subject: MODERATE for lucene-net-user@incubator.apache.org To approve: lucene-net-user- [EMAIL PROTECTED] e.org To reject: lucene-net-user- [EMAIL PROTECTED] e.org To give a reason to reject: %%% Start comment %%% End comment - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Why am I getting those emails? (was: FW: MODERATE for lucene-net-user@incubator.apache.org)
Oh. Oops. I thought he was asking why he started getting those emails after he subscribed to the list. Sorry. -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Sunday, April 23, 2006 9:50 PM To: general@incubator.apache.org Subject: Re: Why am I getting those emails? (was: FW: MODERATE for lucene-net-user@incubator.apache.org) It is sent to the moderators. George is a moderator of that list, as requested at list set up. George - you'll need to reply to it with the [EMAIL PROTECTED] email address. http://www.apache.org/dev/committers.html#mail-moderate - Brett On 4/24/06, James Carman [EMAIL PROTECTED] wrote: Aren't those emails supposed to be sent to the moderators of the list, not to just anyone subscribed to it? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Sunday, April 23, 2006 9:28 PM To: general@incubator.apache.org Subject: Re: Why am I getting those emails? (was: FW: MODERATE for lucene-net-user@incubator.apache.org) Hi George, Try reply all which sends the message to accept plus approve. One is for this single message; the other is a permanent allow. Craig On Apr 23, 2006, at 6:09 PM, George Aroush wrote: Hi folks, Even though I have subscribed to Lucene.Net mailing list, when I submit an email to lucene-net-user@incubator.apache.org I am still getting an email like the one below and it won't appear on the Lucene.Net mailing list until when I approve it. How come? Regards, -- George -Original Message- From: lucene-net-user- [EMAIL PROTECTED] e.org [mailto:lucene-net-user- [EMAIL PROTECTED] or.apache.org] Sent: Sunday, April 23, 2006 9:05 PM To: Recipient list not shown: Cc: lucene-net-user-allow-tc.1145840723.ijpagebdfkdiippacacc- [EMAIL PROTECTED] ncubator.apache.org Subject: MODERATE for lucene-net-user@incubator.apache.org To approve: lucene-net-user- [EMAIL PROTECTED] e.org To reject: lucene-net-user- [EMAIL PROTECTED] e.org To give a reason to reject: %%% Start comment %%% End comment - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Hypothetical New Code Scenario...
All, Suppose the Tapestry TLP project creates a new subproject called Tapestry Commons. Then, I want to add some code that I've developed outside of the ASF to the Tapestry Commons subproject. Does that code have to go through the incubator? My guess is that it does so that we avoid licensing/IP issues. But, I just want to verify. Thanks, James - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Apache RAT
How about ErroRat, a play on Ararat? On 10/24/07, Hiram Chirino [EMAIL PROTECTED] wrote: I like plain rat, and since rat is common word I doubt we have to worry about trademark violations. I also don't confuse it with any other projects in the java space.. so I think it's ok. On 10/23/07, Robert Burrell Donkin [EMAIL PROTECTED] wrote: http://wiki.apache.org/incubator/RatProposal has been stable for a while now so i'd like to throw it open to final scrutiny before i call for a VOTE. (please don't vote yet ;-) the name RAT has been discussed previously - see http://mail-archives.apache.org/mod_mbox/incubator-general/200710.mbox/[EMAIL PROTECTED] RAT is a good name and popular but i'm still a little concerned that there are existing open source projects named RAT as well as commercial software containing RAT in their name. Apache aRAT has the advantage of being unused but the disadvantage of being a common name in some other languages. if anyone strongly disagrees with the consensus that RAT is ok and prefers aRAT please jump in now. - robert Rat Proposal == Abstract -- RAT is comprehension and auditing for distributions and source code. Proposal --- RAT will provide a focus for components, applications and integration tools for the comprehension and audit of distributions and source code. It will collect data and meta-data as required. It will create suitable schemas for this data and meta-data as required. Background -- RAT began as an attempt to automate the technical part of reviewing releases in the incubator. Following requests for access from release managers, RAT was developed as an open source project under the Apache License 2.0. Rationale --- Reviewing releases for compliance with Apache technical criteria and policies is time consuming. The Incubator requires that all releases are reviewed. Though small mistakes are common, this process typically adds only a little value. It is common for candidates to be presented with small but significant defects which then must be fixed and the candidate represented. Significant energy and good will is wasted by this process. This is unnecessary. Given effort, these technical criteria are capable of automation. Automated continuous checking of the source would allow the Incubator PMC to be alerted promptly to potential issues. Integration with build tools (such as Apache Ant and Apache Maven) would allow releases to be checked automatically and continuously. Initial Goals - * Read standard license meta-data for documents without license headers * Improved RAT reporting * RAT source reporting for major build tools * Continuous RAT * RAT analytics: using meta-data to verify rules o Apache third party documents policy analysis o license compatibility analysis * Discordia integration to allow distributed binaries to be recognised * RAT analytic integration for major build tools * Improved recursive RAT scripts for better analysis of release with many distributables Current Status Meritocracy -- I'm very happy to move from a solo development model towards a collective one as more active developers are recruited. Community - The RAT community needs to be developed. Having RAT here at Apache will hopefully encourage release managers to take a more active role in developing RAT. Core Developers It has been developed principally by myself but with significant contributions of small amounts of code from other Apache members and committers. Alignment RAT has found itself becoming a standard part of the Apache release infrastructure. The Incubator needs fully featured release tools. It makes sense to bring the project here. Known Risks == Orphaned Projects -- This is a project with a set of definite goals aimed at serving the wider Apache community. There may well come a time when the coding is actually finished. It has a small set of developers who all have many other calls on their time. The target user audience is relatively small. So, this risk is real. I think that it's clear that something similar to RAT is required. So, unless another better product is developed, time will be found to push RAT forward. Even if one day, RAT is orphaned then it will have done it's job. Inexperience With Open Source - The contributors are Apache members or experienced Apache committers. Reliance On Salaried Developers --- I know of no one who's paid to work on RAT. Relationships with Other Apache Products -- RAT contains an Ant reporting
Re: moving a failed incubation project
I guess the big point here is what is the big issue with changing the package name in the code? When people see a class that's in an org.apache.*package, they assume that it's from the ASF. Leaving it in an ASF-namespaced package has two problems here: 1. People will assume that it's ASF code. 2. The ASF never put its stamp of approval on this code, since it never made it out of the incubator. Neither one of these problems is a legal problem based on the license (from what folks have said here). But, there are certain conventions in the Java community which we follow. If someone sees that code and they want to learn more about it, they'll probably go to www.apache.org and try to find some information. Leaving that code in an ASF-namespaced package is kind of like putting words into someone else's mouth. Another interesting point to all of this is the question of whether the package name really is part of the code. Is the code everything that's in the source file or is the code the actual logic inside the file? The package statement could only be seen as a namespace facility and not necessarily code. I'm no lawyer, but one might try to make that distinction. On 1/23/08, Richard S. Hall [EMAIL PROTECTED] wrote: Niall Pemberton wrote: On Jan 23, 2008 11:26 AM, Simon Kitching [EMAIL PROTECTED] wrote: Niall Pemberton schrieb: On Jan 23, 2008 7:23 AM, Paul Fremantle [EMAIL PROTECTED] wrote: Niall Asking someone politely to rename the package is hardly throwing our weight around. Well you were talking about need to change the package name and rigorous protection rather than some kind of hey we'd prefer it If people are so keen on *protecting* apache in this way then rather than starting with a failed incubator project, then how about this stuff: https://glassfish.dev.java.net/source/browse/glassfish/appserv-webtier/src/java/org/apache/ Again, that is a bit different from the original TCIK issue. It *appears* that here they are not doing this in order to *distribute* a forked copy of tomcat, but instead to support tomcat as an alternative internal servlet-engine implementation within their own j2ee server. In other words, I would think that: (a) you could not normally download this code except by downloading the entire glassfish server, and (b) they are not actively developing this code to add new features (forking) but simply adding a few patches to make it integrate better with Glassfish. The alternate implementations of commons-logging have also been mentioned in this thread. This is not the same IMO. Commons-logging is both an API and an implementation. People should be able to provide alternate implementations of an API, and that is what slf4j are doing for example; they are not providing a patched or forked commons-logging, but instead a complete alternative implementation, and are distributing just the minimum amount of code to provide the same api to users. So: * distributing a few classes in order to implement an apache API : ok * distributing a copy of apache code for the convenience of users of a larger package, perhaps with a few minor tweaks for better integration: ok * publishing code to the world which bears no resemblance to code approved by the ASF: not ok My advice to anyone - read the license yourself, take advice if you feel you need it and ignore all the stuff being spouted here: http://www.apache.org/licenses/LICENSE-2.0.html#redistribution That would be my feeling too. The license pretty much allows people to do whatever they want with the code and the package name is part of the code. - richard Niall All this just just my opinion of course.. Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: moving a failed incubation project
On 1/23/08, Richard S. Hall [EMAIL PROTECTED] wrote: James Carman wrote: I guess the big point here is what is the big issue with changing the package name in the code? When people see a class that's in an org.apache.*package, they assume that it's from the ASF. Leaving it in an ASF-namespaced package has two problems here: 1. People will assume that it's ASF code. 2. The ASF never put its stamp of approval on this code, since it never made it out of the incubator. Neither one of these problems is a legal problem based on the license (from what folks have said here). But, there are certain conventions in the Java community which we follow. If someone sees that code and they want to learn more about it, they'll probably go to www.apache.org and try to find some information. Leaving that code in an ASF-namespaced package is kind of like putting words into someone else's mouth. I didn't say that I was against asking people to change it nicely, but I think there is nothing we can do if they don't. Section 4.b states: You must cause any modified files to carry prominent notices stating that You changed the files; and So, if they make any changes, they must prominently say so, so they wouldn't be putting words into anyone's mouth. If someone downloads the binaries, they don't have the source code, so they'd have to look at the NOTICE file to know what's going on. I doubt many folks actually read those (I typically don't). To me, publishing classes in someone else's namespace (that they didn't author) is like putting words in someone else's mouth. I would imagine other folks feel that way also. The fact that they legally take care of their obligations with respect to the license wouldn't change my perception either. I would still feel uneasy about it. Another interesting point to all of this is the question of whether the package name really is part of the code. Is the code everything that's in the source file or is the code the actual logic inside the file? The package statement could only be seen as a namespace facility and not necessarily code. I'm no lawyer, but one might try to make that distinction. I don't see how you could argue that it is not part of the code, when it impacts the API. The API is the way you talk to the object, or the interface (thus the I in API). The interface consists of the name of the class itself and the names of the methods and fields of the class (whether they be instance or class level). You can change the package name of a library without changing the client logic code. You'll have to use a different namespace to address it (change imports or fully-qualified class names), but the manner in which you use the objects/classes doesn't change. I don't know that I necessarily agree with what I'm saying. I'm just playing devil's advocate. :) In any case, I merely said it was interesting and I don't really know if it's worth wasting anyone else's time here on it (many things I find interesting aren't worth others' time). The main point in this discussion is that not changing the package names is not illegal, but it's definitely uncool and goes against a pretty well adhered to convention. Legally, all we can do is ask them to change the package names and if they don't, there's nothing we can do (at least that's what we're hearing from other folks in this discussion). - richard On 1/23/08, Richard S. Hall [EMAIL PROTECTED] wrote: Niall Pemberton wrote: On Jan 23, 2008 11:26 AM, Simon Kitching [EMAIL PROTECTED] wrote: Niall Pemberton schrieb: On Jan 23, 2008 7:23 AM, Paul Fremantle [EMAIL PROTECTED] wrote: Niall Asking someone politely to rename the package is hardly throwing our weight around. Well you were talking about need to change the package name and rigorous protection rather than some kind of hey we'd prefer it If people are so keen on *protecting* apache in this way then rather than starting with a failed incubator project, then how about this stuff: https://glassfish.dev.java.net/source/browse/glassfish/appserv-webtier/src/java/org/apache/ Again, that is a bit different from the original TCIK issue. It *appears* that here they are not doing this in order to *distribute* a forked copy of tomcat, but instead to support tomcat as an alternative internal servlet-engine implementation within their own j2ee server. In other words, I would think that: (a) you could not normally download this code except by downloading the entire glassfish server, and (b) they are not actively developing this code to add new features (forking) but simply adding a few patches to make it integrate better with Glassfish. The alternate implementations of commons-logging have also been mentioned in this thread. This is not the same IMO. Commons-logging is both an API and an implementation. People should be able
Re: JEUT Champion Recruitment
At that point, aren't you just testing that the ORM implementation works? Wouldn't it be better to make unit tests that test the values of the annotations at runtime? Stuff like: 1. Make sure class X has the @Entity annotation. 2. Make sure its id property has the @Id annotation. 3. Make sure the getter for property foo has the @Basic annotation marking it as required. 4. Make sure the getter for property foo has the @Column annotation making it saved in the FOO column with length 255 If you want to test that the data is actually getting to the database, I'd argue that isn't really a unit test, but an integration test. Now to test queries you write, you'd probably want to use something like HSQLDB to make sure you're getting back the correct data (load some known test data before running tests of course). On Fri, May 16, 2008 at 6:27 AM, Alexis Willemyns [EMAIL PROTECTED] wrote: On a technical note, the best solution is to explain you an example. As for every layer in an application, unit tests are welcome. This is too true for the entities mapped via JPA. So if you want to test an entity, you will create an unit test class (for example with JUnit). In this class, you will add some tests. For example, you will write a test that create an instance of the entity, set values, persist the entity, retrieve the entity, and check if the retrieved object is exactly the same as the persisted entity. It allows you to control that your annotations are matching the definition of the real table in the database. You can do extra tests: check the nullable attribute, the length attribute, the unique constraints, and so on... But if you want to test every aspect of your entity, you will write a big piece of code for each entity! If you have a model with 10, 20 or more entities, you see directly the quantity of work. JEUT is designed to automate for you the testing of an entity. You have just to create a test class that extends a specific JEUT test class and all the work is done for you. The framework uses the annotations discovered via reflection API or the XML files (orm.xml). Do you understand the goal of JEUT? 2008/5/15, Andrus Adamchik [EMAIL PROTECTED]: Hi Alexis, I think it would really help if you started developing in the open using one of the free open source sites. This would provide the project history to a potential Champion, including access to the source code and general feel of whether you are really interested in building community around your code. On a technical note, what exactly does this framework test? Is this regression testing (i.e. checking that the ORM schema matches the actual DB schema), or is there a value beyond that? We had a similar framework submitted to the Cayenne project some time back, and I could never understand what exactly is being tested. Andrus On May 15, 2008, at 9:57 AM, Alexis Willemyns wrote: Hello all, I was a little bit hesitant before posting this project proposition. But let's go! I hope that this attempt will be a success. JEUT stands for JPA Entity Unit Test and is currently in development. So there is no public website and the code is ended up to 70%. JEUT is a testing framework for JPA entities and its main goal is to automate the test of entities without the need to write long and boring home tests. The mission is to provide a framework which is able to test the matching between entities using annotations and/or xml descriptors and the real database. A framework 100% compliant with all the existing annotations in JPA, for the current version 1 (and the future version 2... in the future). JEUT analyzes all the annotations and creates instances of entites with random values. It tries to persist these instances via the entity manager and reports the problems if existing. JEUT can be used as an extension of JUnit or TestNG, or maybe all others test frameworks. For the moment, the team is only composed with me, and I have discussed with my self about what is means to become an Apacha project. I am aware what are the conditions, responsabilities and impacts to become an Apache project. I am looking a Champion to go in the proposal phase (if the proposal makes sense) and to build a community around JEUT. Thank you for any feedback and recommendations (and sorry for my english coming from Belgium). I look forward to your responses. Regards, Alexis Willemyns JEUT project founder - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JEUT Champion Recruitment
This sort of thing should be built into the ORM vendor's implementation. It is with Hibernate. If you set hibernate.hbm2ddl.auto=verify, it will make sure the database is set up correctly based on the mapping settings your application specifies. On Fri, May 16, 2008 at 7:22 AM, Alexis Willemyns [EMAIL PROTECTED] wrote: No I don't think it. The goal is not to test the implementation (Hibernate, Toplink, or another one...) of the JPA specification! Imagine the next case. You have a database engineer, who is for example a Oracle specialist, and you have a backend developper. The db engineer has the responsability to create manually the the db and the associated tables. On another side, the backend developper is responsible of the devolpment of entities (pojos) and he must use the JPA specification. So he will add annotations like @Entity, @Id, @Column, etc... Now the backend developer wants to check that his mapping matches with the work of the db engineer. For example, if he defined a column 'name', he want to ensure that there is a column 'name' defined by the db engineer, that the length is the same, that the unique and nullable factors are the same, and so on... If he want to do that, he must write a unit test, and in this test, persist an instance of the entity, and see if there is an error reported by the JPA implementation. JEUT does the job for you. When you said that it will be good that the framework makes sure that the class has the @Entity annotation, etc,... all these errors will be throwed by the JPA implementation. The goal is not to have an integration test, or to test the JPA implementation, but it's to check the synchonization between the Java pojos (entities) and the physical tables. If the 'name' column is defined as nullable=false via an JPA annotation, we want to be sure that in the table defined by the db engineer, the column is defined with null=false. So for this, in the automated tests of JEUT, an entity with the 'name' field value set to null is persisted and an exception is expected. If there is catched exception (throwed by the persistence implementation), the test is a real success. But if there is no catched exception, it means that the db engineer didn't define the column with null=false, and the test fails! Here is another example. In JPA, you can create date, time and timestamp via @Temporal annotation. If the backend developer defines a column with temporal type as date and the db engineer defines the column with time type, all the information about the day, the month and the year are lost. So JEUT tests the matching for the dates, and will find the previous error of mapping. JEUT is compatible all db server, the framework will use the META-INF/persistence.xml defined in the test source folder in the application of the user. So the user can test with the oracle db, hsqldb, derby, mysql,... It's not easy to explain! Is it more clear? Alexis 2008/5/16, James Carman [EMAIL PROTECTED]: At that point, aren't you just testing that the ORM implementation works? Wouldn't it be better to make unit tests that test the values of the annotations at runtime? Stuff like: 1. Make sure class X has the @Entity annotation. 2. Make sure its id property has the @Id annotation. 3. Make sure the getter for property foo has the @Basic annotation marking it as required. 4. Make sure the getter for property foo has the @Column annotation making it saved in the FOO column with length 255 If you want to test that the data is actually getting to the database, I'd argue that isn't really a unit test, but an integration test. Now to test queries you write, you'd probably want to use something like HSQLDB to make sure you're getting back the correct data (load some known test data before running tests of course). On Fri, May 16, 2008 at 6:27 AM, Alexis Willemyns [EMAIL PROTECTED] wrote: On a technical note, the best solution is to explain you an example. As for every layer in an application, unit tests are welcome. This is too true for the entities mapped via JPA. So if you want to test an entity, you will create an unit test class (for example with JUnit). In this class, you will add some tests. For example, you will write a test that create an instance of the entity, set values, persist the entity, retrieve the entity, and check if the retrieved object is exactly the same as the persisted entity. It allows you to control that your annotations are matching the definition of the real table in the database. You can do extra tests: check the nullable attribute, the length attribute, the unique constraints, and so on... But if you want to test every aspect of your entity, you will write a big piece of code for each entity! If you have a model with 10, 20 or more entities, you see directly the quantity of work. JEUT is designed to automate for you the testing of an entity. You have just
Re: JEUT Champion Recruitment
Well, one of our unit tests is called TestTargetDatabaseSchema and in
that test I do:
@Test
public void verifySchema()
{
SchemaValidator validator = new SchemaValidator(getConfiguration());
validator.validate();
}
We also found it useful to actually spit out the DDL that hibernate
would use to generate the schema itself (if you use
hibernate.hbm2ddl.auto=create-drop):
@Test
public void exportSchema()
{
final SchemaExport export = new SchemaExport(getConfiguration());
final File outputFile = new File(target/sql/schema.sql);
outputFile.getParentFile().mkdirs();
export.setOutputFile(outputFile.getAbsolutePath());
export.create(false,false);
}
We use maven2, so the target directory is a common location for build
artifacts. The getConfiguration() method merely sets up the Hibernate
configuration object. Hope this helps!
On Fri, May 16, 2008 at 9:30 AM, Alexis Willemyns
[EMAIL PROTECTED] wrote:
So, with the solution of hibernate.hbm2ddl.auto=validate, you don't need
to write a unit test? If it's the case, the JEUT framework doesn't have any
sense. I will test this solution!
2008/5/16, James Carman [EMAIL PROTECTED]:
This sort of thing should be built into the ORM vendor's
implementation. It is with Hibernate. If you set
hibernate.hbm2ddl.auto=verify, it will make sure the database is set
up correctly based on the mapping settings your application specifies.
On Fri, May 16, 2008 at 7:22 AM, Alexis Willemyns
[EMAIL PROTECTED] wrote:
No I don't think it. The goal is not to test the implementation
(Hibernate,
Toplink, or another one...) of the JPA specification!
Imagine the next case. You have a database engineer, who is for example a
Oracle specialist, and you have a backend developper. The db engineer has
the responsability to create manually the the db and the associated
tables.
On another side, the backend developper is responsible of the devolpment
of
entities (pojos) and he must use the JPA specification. So he will add
annotations like @Entity, @Id, @Column, etc...
Now the backend developer wants to check that his mapping matches with
the
work of the db engineer. For example, if he defined a column 'name', he
want
to ensure that there is a column 'name' defined by the db engineer, that
the
length is the same, that the unique and nullable factors are the same,
and
so on... If he want to do that, he must write a unit test, and in this
test,
persist an instance of the entity, and see if there is an error reported
by
the JPA implementation. JEUT does the job for you.
When you said that it will be good that the framework makes sure that the
class has the @Entity annotation, etc,... all these errors will be
throwed
by the JPA implementation. The goal is not to have an integration test,
or
to test the JPA implementation, but it's to check the synchonization
between
the Java pojos (entities) and the physical tables. If the 'name' column
is
defined as nullable=false via an JPA annotation, we want to be sure that
in
the table defined by the db engineer, the column is defined with
null=false.
So for this, in the automated tests of JEUT, an entity with the 'name'
field
value set to null is persisted and an exception is expected. If there is
catched exception (throwed by the persistence implementation), the test
is a
real success. But if there is no catched exception, it means that the db
engineer didn't define the column with null=false, and the test fails!
Here is another example. In JPA, you can create date, time and timestamp
via
@Temporal annotation. If the backend developer defines a column with
temporal type as date and the db engineer defines the column with time
type,
all the information about the day, the month and the year are lost. So
JEUT
tests the matching for the dates, and will find the previous error of
mapping.
JEUT is compatible all db server, the framework will use the
META-INF/persistence.xml defined in the test source folder in the
application of the user. So the user can test with the oracle db, hsqldb,
derby, mysql,...
It's not easy to explain!
Is it more clear?
Alexis
2008/5/16, James Carman [EMAIL PROTECTED]:
At that point, aren't you just testing that the ORM implementation
works? Wouldn't it be better to make unit tests that test the
values of the annotations at runtime? Stuff like:
1. Make sure class X has the @Entity annotation.
2. Make sure its id property has the @Id annotation.
3. Make sure the getter for property foo has the @Basic annotation
marking it as required.
4. Make sure the getter for property foo has the @Column annotation
making it saved in the FOO column with length 255
If you want to test that the data is actually getting to the database,
I'd argue that isn't really a unit test, but an integration test.
Now to test queries you write, you'd probably want to use something
Re: JEUT Champion Recruitment
I do not use Toplink, so I wouldn't be a good person to answer that
question. I'm glad the Hibernate stuff could help you, though. We've
found that to be a lifesaver in our project.
On Fri, May 16, 2008 at 9:45 AM, Alexis Willemyns
[EMAIL PROTECTED] wrote:
Yes it seems to work perfectly. Is there an equivalent for Toplink of
Oracle?
2008/5/16, James Carman [EMAIL PROTECTED]:
Well, one of our unit tests is called TestTargetDatabaseSchema and in
that test I do:
@Test
public void verifySchema()
{
SchemaValidator validator = new SchemaValidator(getConfiguration());
validator.validate();
}
We also found it useful to actually spit out the DDL that hibernate
would use to generate the schema itself (if you use
hibernate.hbm2ddl.auto=create-drop):
@Test
public void exportSchema()
{
final SchemaExport export = new SchemaExport(getConfiguration());
final File outputFile = new File(target/sql/schema.sql);
outputFile.getParentFile().mkdirs();
export.setOutputFile(outputFile.getAbsolutePath());
export.create(false,false);
}
We use maven2, so the target directory is a common location for build
artifacts. The getConfiguration() method merely sets up the Hibernate
configuration object. Hope this helps!
On Fri, May 16, 2008 at 9:30 AM, Alexis Willemyns
[EMAIL PROTECTED] wrote:
So, with the solution of hibernate.hbm2ddl.auto=validate, you don't
need
to write a unit test? If it's the case, the JEUT framework doesn't have
any
sense. I will test this solution!
2008/5/16, James Carman [EMAIL PROTECTED]:
This sort of thing should be built into the ORM vendor's
implementation. It is with Hibernate. If you set
hibernate.hbm2ddl.auto=verify, it will make sure the database is set
up correctly based on the mapping settings your application specifies.
On Fri, May 16, 2008 at 7:22 AM, Alexis Willemyns
[EMAIL PROTECTED] wrote:
No I don't think it. The goal is not to test the implementation
(Hibernate,
Toplink, or another one...) of the JPA specification!
Imagine the next case. You have a database engineer, who is for
example a
Oracle specialist, and you have a backend developper. The db engineer
has
the responsability to create manually the the db and the associated
tables.
On another side, the backend developper is responsible of the
devolpment
of
entities (pojos) and he must use the JPA specification. So he will add
annotations like @Entity, @Id, @Column, etc...
Now the backend developer wants to check that his mapping matches with
the
work of the db engineer. For example, if he defined a column 'name',
he
want
to ensure that there is a column 'name' defined by the db engineer,
that
the
length is the same, that the unique and nullable factors are the same,
and
so on... If he want to do that, he must write a unit test, and in this
test,
persist an instance of the entity, and see if there is an error
reported
by
the JPA implementation. JEUT does the job for you.
When you said that it will be good that the framework makes sure that
the
class has the @Entity annotation, etc,... all these errors will be
throwed
by the JPA implementation. The goal is not to have an integration
test,
or
to test the JPA implementation, but it's to check the synchonization
between
the Java pojos (entities) and the physical tables. If the 'name'
column
is
defined as nullable=false via an JPA annotation, we want to be sure
that
in
the table defined by the db engineer, the column is defined with
null=false.
So for this, in the automated tests of JEUT, an entity with the 'name'
field
value set to null is persisted and an exception is expected. If there
is
catched exception (throwed by the persistence implementation), the
test
is a
real success. But if there is no catched exception, it means that the
db
engineer didn't define the column with null=false, and the test fails!
Here is another example. In JPA, you can create date, time and
timestamp
via
@Temporal annotation. If the backend developer defines a column with
temporal type as date and the db engineer defines the column with time
type,
all the information about the day, the month and the year are lost. So
JEUT
tests the matching for the dates, and will find the previous error of
mapping.
JEUT is compatible all db server, the framework will use the
META-INF/persistence.xml defined in the test source folder in the
application of the user. So the user can test with the oracle db,
hsqldb,
derby, mysql,...
It's not easy to explain!
Is it more clear?
Alexis
2008/5/16, James Carman [EMAIL PROTECTED]:
At that point, aren't you just testing that the ORM implementation
works? Wouldn't it be better to make unit tests that test the
values of the annotations at runtime? Stuff like:
1. Make sure class X has
Re: [PROPOSAL] Incubate JSecurity Project
Isn't there something that states that an incubating project needs to be novel or provide something that's not already provided by another library (with an open-source license)? I have looked at the JSecurity proposal only briefly, but it seems to me that most of what it aims to provide is already provided by Spring Security (a.k.a. Acegi). Although, Spring Security is somewhat bound to the Spring framework (they implement InitializingBean and stuff), so that might be what JSecurity is trying to provide, a container-agnostic security framework. On Fri, May 30, 2008 at 2:32 AM, Bertrand Delacretaz [EMAIL PROTECTED] wrote: Hi, On Wed, May 28, 2008 at 11:19 PM, Alan D. Cabrera [EMAIL PROTECTED] wrote: ...http://wiki.apache.org/incubator/JSecurityProposal... Looks good to me, IMHO this is ready for a vote. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Incubate JSecurity Project
On Fri, May 30, 2008 at 8:31 AM, Jeremy Haile [EMAIL PROTECTED] wrote: Another differentiator is that JSecurity provides a session framework that is not limited to being shared across just web-based applications. We have users that share sessions across multiple environments, such as Swing apps talking to a server over Spring remoting or RMI, applets, and web applications - so they can all share common session information in a heterogeneous environment. I like this idea! We have an application that has a Swing client and we talk to the server via Spring remoting. This shared session idea sounds intriguing. I might have to look into switching to JSecurity! :) This simplicity and power is unmatched in any existing security framework out-of-the-box. Finally, JSecurity strives for simplicity in all areas. To this end, it explicitly supports common security mechanisms used in most applications such as roles and permissions. This makes code more readable, limits the amount of custom coding required, and makes security definitions very concise and readable. Despite our goals of simplicity we also aim for flexibility - so out of the box the framework should be extremely easy to get up and running, requiring minimal configuration and custom code. But for users who have much more advanced needs, JSecurity provides the pluggability and extensibility to be used for almost any security application. The simplicity is definitely needed. Spring Security is confusing at times. They've tried to clean things up a bit in the latest version(s), but it's still tough to wrap your head around. I usually just copy/paste something that I know works. :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven repository
On Fri, May 30, 2008 at 8:56 AM, Robert Burrell Donkin [EMAIL PROTECTED] wrote: in terms of communication, the pom is the place to focus. AIUI maven users choose to use a library by adding a dependency with artifact and group IDs. an easy and effective way to ensure that users know that they are using an artifact from the incubator would be to ensure that the group or artifact ID includes this information. we could also ask that the pom (meta-data) for the project specifies 'Apache Software Foundation (Incubator)' rather than 'Apache Software Foundation' as the organisation. Maven artifacts can also specify a classifier. Perhaps the incubating part could be a classifier? dependency groupIdorg.apache.podling/groupId artifactIdpodling/artifactId version2.0/version classifierincubating/classifier /dependency - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven repository
On Fri, May 30, 2008 at 9:22 AM, Brian E. Fox [EMAIL PROTECTED] wrote: Maven artifacts can also specify a classifier. Perhaps the incubating part could be a classifier? Only attached artifacts can have a classifier, not the main one, so unfortunately this won't work. I think having a different groupId is the most logical choice... something like org.apache.incubator. Wouldn't having incubating in the version achieve the same thing here? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven repository
Well, to avoid collisions like that you could change the package name: org.apache.incubating.podlingname Once it graduates, you get: org.apache.podlingname On Fri, May 30, 2008 at 10:28 AM, Brian E. Fox [EMAIL PROTECTED] wrote: The problem with that is when the project graduates and they remove incubator from the groupId, there is a good potential to have two versions of the same packages being pulled in You're right, I overlooked that... so I guess the qualifier attached to the version is probably the best bet. --Brian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven repository
On Fri, May 30, 2008 at 10:51 AM, Brian E. Fox [EMAIL PROTECTED] wrote: You would still end up with duplicate jars being drawn in. Maven fingerprints an artifact with groupId:artifactid:classifier:type to see if there are conflicts. Of course, but you can make sure folks aren't using the podling version of the code vs. the graduated if they're in different packages. We are using a similar strategy within Apache Commons to avoid jar hell situations. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven repository
On Fri, May 30, 2008 at 10:54 AM, Noel J. Bergman [EMAIL PROTECTED] wrote: End users don't read the POM. They just use it. So that is no solution at all. The signing approach would be, IMO, a reasonable solution. It would solve Les' issue -- users would simply have to agree to install the Incubator-signed artifact(s), and thereafter they'd be fine. Users do use the code, though. Putting the code in an incubating package (for Java-based projects) does make them aware that they're using an incubating library. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven repository
The bottom line is that incubator projects haven't (yet) gone through all the hoops necessary to become official ASF projects. So, if they are published to the main repository, that is in a way saying that the ASF endorses the software. Since it has not graduated from the incubator, the ASF doesn't yet endorse it. This is the way I see it at least. On Fri, May 30, 2008 at 11:06 AM, Les Hazlewood [EMAIL PROTECTED] wrote: Noel, Could you please help me understand the fundamental reasons why this is important to the IPMC? I mean, I as an end-user could care less about if the dependency artifact is in incubation or not - as long as it solves the problems in the way the development team deems necessary, all I want to do is just have be accessible to me immediately. I don't care where it comes from. If it requires intervention on my part, I view that as a major pain, especially if it can knowingly be avoided. I would want things to be as automatic and hands-off as possible. I'm just genuinely trying to understand why the distinction is necessary. Thanks for clarifying my naivety, Les On Fri, May 30, 2008 at 10:54 AM, Noel J. Bergman [EMAIL PROTECTED] wrote: Robert Burrell Donkin wrote: it has now been clearly established that we need to move the repository. we're now just asking: where? As I said, Brett Porter's proposal, made early on in the thread, seemed satisfactory. asking podlings to publish through a secondary repository is both annoying and ineffective at making it explicit to people that they are using artifacts under incubation. this measure cuts against the grain of maven. I really don't care what cuts across the grain of Maven. I do care about the established principle that people must make a deliberate decision to use Incubator artifacts. If Maven would finally support enforcing signing of artifacts, as they have been asked to do for years, we could use an Incubator-specific signing key, forcing people to approve the use of Incubator artifacts, regardless of download location. Rather than relax the principle to accomodate a defective tool, if Maven cannot solve this problem, I'd be more inclined to ban the use of maven repositories for Incubator artifacts. That is how strongly I feel about the principle. By the way, there has been some talk in Infrastructure about shutting down the ASF's repository entirely if Maven does not provide enforcement of signed artifacts, due to security concerns. Look back over the years of debate on this issue, and I believe that you will find I've been very consistent. I want Incubator projects to be able to perform releases in order to grow their (developer) community, but we also require that people be aware of the fact that they are not using official ASF code, as noted by the disclaimer. an easy and effective way to ensure that users know that they are using an artifact from the incubator would be to ensure that the group or artifact ID includes this information. End users don't read the POM. They just use it. So that is no solution at all. The signing approach would be, IMO, a reasonable solution. It would solve Les' issue -- users would simply have to agree to install the Incubator-signed artifact(s), and thereafter they'd be fine. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven repository
On Fri, May 30, 2008 at 11:23 AM, Jeremy Haile [EMAIL PROTECTED] wrote: So it seems that a valid question is whether or not publishing to one repository or another indicates an endorsement. Yes, that's certainly a valid question. Again, that's just my personal point of view. The biggest problem with incubator projects (again my opinion) having releases is the IP clearance. Perhaps there should be multiple stages of incubation. The first stage should be where you verify the IP clearance and projects in that stage shouldn't be allowed to do releases at all. Then they might graduate to the next stage and that would be a community building stage where we make sure the project has enough community around it. These projects should be able to provide incubating releases. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Incubate JSecurity Project
On Fri, May 30, 2008 at 8:27 AM, Alex Karasulu [EMAIL PROTECTED] wrote: There's no uniqueness requirement AFAIK. Any kind of project can be proposed even if there already exist multiple implementations of a similar technology here at the ASF and abroad. Perhaps the uniqueness/novel restriction is for Apache Commons projects. Or, perhaps I just made it up out of thin air! :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Incubate JSecurity Project
On Fri, May 30, 2008 at 12:03 PM, Emmanuel Lecharny [EMAIL PROTECTED] wrote: Maven vs Ant vs Buildr ? Who uses Ant or Buildr? ;) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven repository
So, let's define the goals here: 1. The ASF would like folks who want to use incubating projects to do so knowingly somehow. This is somewhat of a CYA tactic so that people are acknowledging yes, I understand this is not an 'official' ASF project, but I'd like to use it anyway. 2. Incubating projects would like to be able to get releases in front of people so that they can build their community. On Fri, May 30, 2008 at 11:43 AM, Les Hazlewood [EMAIL PROTECTED] wrote: Hrm - I thought you had to have IP clearance before you even were accepted as a podling. Or maybe its just that Alan is such a great Champion for us, that he helped us along that path before we even submitted our proposal ;) Under this assumption (that IP clearance exists already), it makes much more sense to allow the podling to publish approved releases to the central repository, but still under an org.apache.incubator.projectname group id to maintain convention/simplicity. On Fri, May 30, 2008 at 11:38 AM, James Carman [EMAIL PROTECTED] wrote: On Fri, May 30, 2008 at 11:23 AM, Jeremy Haile [EMAIL PROTECTED] wrote: So it seems that a valid question is whether or not publishing to one repository or another indicates an endorsement. Yes, that's certainly a valid question. Again, that's just my personal point of view. The biggest problem with incubator projects (again my opinion) having releases is the IP clearance. Perhaps there should be multiple stages of incubation. The first stage should be where you verify the IP clearance and projects in that stage shouldn't be allowed to do releases at all. Then they might graduate to the next stage and that would be a community building stage where we make sure the project has enough community around it. These projects should be able to provide incubating releases. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven repository
On Fri, May 30, 2008 at 5:17 PM, Janne Jalkanen [EMAIL PROTECTED] wrote: As an end user, I would _hate_ to have to change all of my code to reference a totally new package structure after the podling graduates. That's a major pain... With JSPWiki we have plenty of plugins and other extensions donated by people over the years. Every binary break means that we obsolete most of this stuff (unless we can take the responsibility of recompiling everything). Every binary break means that we will have to answer questions from people running obsolete software because they can't afford the cost of the upgrade because they have money invested in the customizations. So it's not only the pain of upgrading the package definitions; changing packages issues a damaging blow to the ecosystem nurtured in the incubator. Sometimes the impact can be minimal; sometimes it could be rather bad. The package names have to change when a podling comes into the incubator (to the org.apache namespace). So, the blow has to happen anyway. I'm not suggesting we enforce this for existing podlings necessarily, but future ones should probably do it. Once the podling graduates, the plugins would need to change the package name they use because they are now based on an official ASF library. Is find/replace really that difficult? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: enforced signing of artifacts, [was maven repository]
On Sat, May 31, 2008 at 1:33 AM, Robert Burrell Donkin [EMAIL PROTECTED] wrote: IMO this isn't really a maven issue: basic checks should be performed on all releases. i favour a private subversion repository with custom hooks for release publishing. I think it very much is a maven issue. Maven is the tool that automatically downloads jar files from the public repository automagically (I love that by the way). If there were a setting in maven that I could set that says don't add anything to my local maven repository that isn't signed by someone that I trust, then I think we would be good here. I don't know if I'd make it a required feature, though. I think making it optional would be okay. Maven should also ask you if you want to trust a signer if it hasn't seen it before (kind of like how webstart does). Perhaps it could be a three-choice setting: 1. Allow any jars from the central repository. 2. Ask me before allowing jars from someone I haven't specifically trusted before. 3. Don't allow any jars signed by people I do not trust. This, of course, would mean that we should probably set up a release signing committee so that we only use one signing key from the ASF (users shouldn't have to say that they trust jars signed by me, and Robert, and Brett, and Noel). The members of the committee would be the only ones with write access to the maven rsync directory. The requests could be set up in JIRA or something (hopefully there would be a committee member on each PMC). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: enforced signing of artifacts, [was maven repository]
On Sat, May 31, 2008 at 9:05 AM, James Carman [EMAIL PROTECTED] wrote: On Sat, May 31, 2008 at 1:33 AM, Robert Burrell Donkin [EMAIL PROTECTED] wrote: IMO this isn't really a maven issue: basic checks should be performed on all releases. i favour a private subversion repository with custom hooks for release publishing. I think it very much is a maven issue. Maven is the tool that automatically downloads jar files from the public repository automagically (I love that by the way). If there were a setting in maven that I could set that says don't add anything to my local maven repository that isn't signed by someone that I trust, then I think we would be good here. I don't know if I'd make it a required feature, though. I think making it optional would be okay. Maven should also ask you if you want to trust a signer if it hasn't seen it before (kind of like how webstart does). Perhaps it could be a three-choice setting: 1. Allow any jars from the central repository. 2. Ask me before allowing jars from someone I haven't specifically trusted before. 3. Don't allow any jars signed by people I do not trust. This, of course, would mean that we should probably set up a release signing committee so that we only use one signing key from the ASF (users shouldn't have to say that they trust jars signed by me, and Robert, and Brett, and Noel). The members of the committee would be the only ones with write access to the maven rsync directory. The requests could be set up in JIRA or something (hopefully there would be a committee member on each PMC). I guess we would probably want to set up a signing key for each PMC. Since saying that I approve of using releases from one podling doesn't necessarily mean I approve of using releases from another podling. For example, I may trust JSecurity if I am a long-time user of it, but I don't trust Imperius, because I don't know what the heck it is. Once a podling graduates, would we need to generate a new signing key for it (without the incubating)? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven repository
On Sun, Jun 1, 2008 at 11:59 AM, Noel J. Bergman [EMAIL PROTECTED] wrote: FWIW, I agree with James that we would use signing to be more fine-grained, but didn't want to go into that degree of detail in the earlier discussion. I apologize for being so verbose. This is probably not the correct forum to discuss those changes at that level of detail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven-repository cont.
On Mon, Jun 2, 2008 at 10:52 AM, sebb [EMAIL PROTECTED] wrote: On 02/06/2008, Guillaume Nodet [EMAIL PROTECTED] wrote: On Fri, May 30, 2008 at 2:53 PM, Brian E. Fox [EMAIL PROTECTED] wrote: 1. Incubator releases go into Central +1 I think having the incubator or incubating word in the version name brings sufficient awareness to the users. But Maven does not warn about using incubator versions. If you are adding a direct dependency on an incubator version, then the user may understand the significance of the word. Or they may not, depending on whether they understand the jargon correctly. But if the dependency is a transitive one, then the user does not get to know about this (unless they scan the maven log very carefully) And who does that!?!? :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven-repository cont.
On Mon, Jun 2, 2008 at 12:17 PM, Brian E. Fox [EMAIL PROTECTED] wrote: Part of the Incubation process is to ensure that there is sufficient community to maintain the code after incubation. It seems a bad idea to allow artefacts into the main repository where they can become dependencies unless there is some chance that they will be maintained. This is an argument for saying that TLP Apache projects can't depend on incubator artifacts then. Otherwise those projects suddenly don't work because a dependency disappeared. I personally don't think this should be the case. If they are released and someone wants to use them, then they should go into central where they live forever like everything else. Just because the community goes away does not mean the artifact should disappear too. But, doesn't that somewhat hurt the Apache name if we have a bunch of orphaned projects sitting out there in limbo with our name on it? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Incubate JSecurity Project
+1 (non-binding) On Mon, Jun 2, 2008 at 11:05 AM, Alan D. Cabrera [EMAIL PROTECTED] wrote: Relevant information can be found in: http://wiki.apache.org/incubator/JSecurityProposal Regards, Alan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: photo gallery software (previously called Caitrin)
So, does this photo gallery software currently exist or are you trying to start a new project? On Wed, Jul 2, 2008 at 12:36 PM, Luciano Resende [EMAIL PROTECTED] wrote: I have started some discussions on getting a prototype based on Tuscany + Sling [1]. The code will be available at [2] [1] http://www.mail-archive.com/dev%40tuscany.apache.org/msg00442.html [2] https://svn.apache.org/repos/asf/tuscany/java/sca/samples/photo-gallery/ On Tue, Jul 1, 2008 at 5:00 AM, Carsten Ziegeler [EMAIL PROTECTED] wrote: Hi, Angela Cymbalak wrote: Is there somewhere that I can take a look at the code? Would you mind if it were drawn from for a new project? No, the code is not yet available - but I hope to commit it around the weekend. I'll you know. Feel free to use it, or withdraw the idea after looking at it :) Carsten -- Carsten Ziegeler [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: photo gallery software (previously called Caitrin)
Ok, so we're talking about incubating an idea, then? On Wed, Jul 2, 2008 at 10:27 PM, Noel J. Bergman [EMAIL PROTECTED] wrote: o, does this photo gallery software currently exist or are you trying to start a new project? There are several codebases (Angie's, mine, and others), but basically, a new project. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: photo gallery software (previously called Caitrin)
If it's a new project, then why does it have to be incubated? Couldn't we just start up a labs project to tinker around with the idea. Then, when/if it builds up enough steam, promote it to a TLP? On Wed, Jul 2, 2008 at 10:27 PM, Noel J. Bergman [EMAIL PROTECTED] wrote: o, does this photo gallery software currently exist or are you trying to start a new project? There are several codebases (Angie's, mine, and others), but basically, a new project. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: photo gallery software (previously called Caitrin)
On Thu, Jul 3, 2008 at 10:25 AM, Bertrand Delacretaz [EMAIL PROTECTED] wrote: On Thu, Jul 3, 2008 at 4:11 PM, Angela Cymbalak [EMAIL PROTECTED] wrote: Isn't labs for something already inside of Apache and the Incubator for things outside of Apache? labs is for existing Apache committers, and labs are not allowed to release software. More at http://labs.apache.org/ And since currently this software project is merely an idea (along with some previously tinkered with codebases), I'd say it's a perfect candidate for a lab. It doesn't sound like it's ready for a release just yet. :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: photo gallery software (previously called Caitrin)
On Thu, Jul 3, 2008 at 11:00 AM, Luciano Resende [EMAIL PROTECTED] wrote: As bertrand mentioned, Labs are for existing committers only, and Angela, who is proposing the project isn't a committer. Sorry, I saw Noel's comment about there being many codebases and thought he was party proposing this project (I'm pretty sure Noel's a committer :). So, perhaps start this project somewhere else first (get some code) and bring it to the incubator then. I didn't think the incubator was for codeless projects (my perception only and I have absolutely no documentation to support that :). Either way you go (labs vs. incubator), you're going to have to set up Angela as a committer somewhere. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: photo gallery software (previously called Caitrin)
On Thu, Jul 3, 2008 at 7:46 PM, Noel J. Bergman [EMAIL PROTECTED] wrote: since currently this software project is merely an idea (along with some previously tinkered with codebases), I'd say it's a perfect candidate for a lab. It doesn't sound like it's ready for a release just yet. :) When were either of those two things criteria for Incubation? And there is code, but to give credit, the project is prepared to discard all of it in order to build community. Which two things? As I said, the codeless project stuff was merely my understanding, whether it's based on actual facts or not I have no idea. The release part was mentioned because they said that labs projects can't do releases. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Installers for couchdb
Doesn't requiring a library with an excluded license pretty much throw the apache license part out the window? Are these optional dependencies? Will couchdb run at all without them? On Wed, Jul 9, 2008 at 12:12 PM, Craig L Russell [EMAIL PROTECTED] wrote: On Jul 9, 2008, at 9:37 AM, Philippe Ombredanne wrote: Howdy: I am working on couchdb installers that I would like to contribute back to the project: A fully functional CouchDb install has a few external dependencies such as: - ICU (ICU License a BSD/MIT style license) - Mozilla SpiderMonkey (MPL, GPL or LGPL) - Erlang (ERLANG PUBLIC LICENSE) - Openssl (OpenSSL license, a BSD style license) My understanding is that it would not be acceptable IP-clearance wise to have all (though some may be) those bits shipped as part of all-inclusive installers. That's my understanding of the current consensus as well. My request: Would it be acceptable to create installers that would fetch at install time the required external bits from their original download locations? Those fetch operations would be clearly presented as external fetch operationsto the users. I think the current operative policy is from http://www.apache.org/legal/3party.html: • For add-ons under excluded licenses, the PMC may provide a link/reference on the product web site or within product documentation to some other web site that hosts such add-ons (e.g. a SF.net project or some third-party site dedicated to distributing add-ons for the Apache product) as long as it is made clear to users that the host site is not part of the Apache product nor endorsed by the ASF. • For add-ons under excluded licenses, the PMC may include a feature within the product that allows the user to obtain third-party add-ons if the feature also alerts the user of the associated license and makes clear to users that the host site is not part of the Apache product nor endorsed by the ASF. So as long as your installer makes it clear to the user that the external bits are not Apache-licensed, I read the policy as allowing the CouchDb installer to fetch and install them and thereby make them available to the CouchDb user. Craig Cordially -- Cheers Philippe philippe ombredanne | 1 650 799 0949 | pombredanne at nexb.com nexB - Open by Design (tm) - http://www.nexb.com http://easyeclipse.org - http://phpeclipse.net - http://eclipse.org/atf - http://eclipse.org/vep - http://labs.jboss.org/drools/ - http://developer.mozilla.org/en/docs/XULRunner - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Craig L Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Installers for couchdb
On Wed, Jul 9, 2008 at 1:21 PM, Santiago Gala [EMAIL PROTECTED] wrote: El mié, 09-07-2008 a las 12:41 -0400, James Carman escribió: Doesn't requiring a library with an excluded license pretty much throw the apache license part out the window? Are these optional dependencies? Will couchdb run at all without them? The way I see it Erlang can be considered a platform dependency, much like java. i.e., no java Apache project runs without java, and java is not even Open Source. Trying to bundle it in unmodified form for an installer brings issues, but no more issues than installing a java runtime does, for instance. Yes, Erlang is fine I would think. As you said, it's like requiring a JVM. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] Do we really need an incubator?
On Sat, Jul 12, 2008 at 4:14 PM, Paul Querna [EMAIL PROTECTED] wrote: However, AFAIK, CPAN doesn't allow every CPAN author to overwrite the files of every other CPAN author. Thats the situation we are in now with the Maven Repository, because we just use the filesystem on people.apache.org as the pristine copy. Which is why I suggested we put our Maven repository contents into SVN and only give write permissions to certain trusted individuals. That way, we could SVN export the contents of our repository to some directory that can be rsynced to the main repo. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept project PicaGalley into the Incubator
How about phoshow? Photo/Show :) On Tue, Aug 5, 2008 at 12:14 PM, Roland Weber [EMAIL PROTECTED] wrote: Jukka Zitting wrote: I also think the names are too similar I have re-opened the naming discussion on [EMAIL PROTECTED] Should we keep this vote running, or should we start a new one after we settle for a different name? cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept project PicaGalley into the Incubator
Oops. Sorry: http://whatstoeatla.blogspot.com/2008/06/phoshowi-swear-i-didnt-make-it-up.html I was half kidding. I think phoshizzle is out too :( On Tue, Aug 5, 2008 at 12:16 PM, James Carman [EMAIL PROTECTED] wrote: How about phoshow? Photo/Show :) On Tue, Aug 5, 2008 at 12:14 PM, Roland Weber [EMAIL PROTECTED] wrote: Jukka Zitting wrote: I also think the names are too similar I have re-opened the naming discussion on [EMAIL PROTECTED] Should we keep this vote running, or should we start a new one after we settle for a different name? cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: status of PGP support in Maven
Eclipse does something like this, doesn't it? When you install a plugin, it asks you to accept the license terms for all the stuff that's being imported. Couldn't maven do something similar? On Mon, Sep 22, 2008 at 9:34 AM, Hiram Chirino [EMAIL PROTECTED] wrote: The only reason I suggested including the sigs in the source distro is because a source build like Apache ServiceMix depends on hundreds of third party dependencies.. so an end user would need to end up trusting LOTs different signatures to get ServiceMix to build. It would be easier if the end user could just trust the Apache source distro and also transitively trust the signatures that we trust for our dependencies. The end user would still need to manually validate the source distro signature. Regards, Hiram On Sat, Sep 20, 2008 at 1:08 PM, Henning Schmiedehausen [EMAIL PROTECTED] wrote: On Sat, 2008-09-20 at 10:08 +0100, Robert Burrell Donkin wrote: On Fri, Sep 19, 2008 at 6:11 PM, Justin Erenkrantz [EMAIL PROTECTED] wrote: On Fri, Sep 19, 2008 at 6:12 AM, Hiram Chirino [EMAIL PROTECTED] wrote: How about we include the signatures in the source distros? That way if you trust your source, then you can trust the dependencies it downloads. Eww. That'd be a giant gaping security hole. not necessarily, depends how it's done signing works through trusting the people who own the keys. given sufficient signaturees (to prevent small conspiracies), where the signatures are downloaded from shouldn't matter. Hiram suggested to put the signatures into the source, which in turn is also distributed from the repo. If you compromise the repo and change the artifact, it is trivial to update the source artifact to contain a matching signature. This is a security hole. And I don't really care for some of the proposed high nineties security solutions. Either a solution is secure or it is not. Everything else is just FUD. The problem with the central repo is that you need an easy accessible web of trust if you want validation. The Apache web of trust is distributed and an overlay to the GPG web of trust. But if you live in Juneau, Alaska, it is hard for you to access it and get a trust relationship to it. There is a (bit rusty) proposal on how to improve this at http://people.apache.org/~henkp/trust/ Ciao Henning - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Regards, Hiram Blog: http://hiramchirino.com Open Source SOA http://open.iona.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] Names for the Web2.0kit
No longer any known fluent speakers Perhaps we should have a COBOL implementation, then. :) On Tue, Sep 23, 2008 at 1:58 PM, Bruno Borges [EMAIL PROTECTED] wrote: By the way, I forgot to mention that Jawi has everything to do with Java (the Island... @ Malaysia). Quoting Wikipedia (http://en.wikipedia.org/wiki/Jawi,_Penang): Jawi is a town on the mainland side of Penang, Malaysia. And for those who can't go to Wikipedia to check what Jawi is, here is the rest: Jawi is a nearly extinct Australian Aboriginal language of Western Australia, the traditional language of the Jawi people. There are no longer any known fluent speakers, but there may be some partial speakers. http://en.wikipedia.org/wiki/Jawi_language cheers! Bruno Borges wrote: Olio sounds good, but there's nothing related with Java, Web, frameworks or anything else... (or, is just me who couldn't find any information about this word?) So, because of the lack of co-relation between Olio and Java Webkits, I found that there's an word which could fit better: Jawi http://en.wikipedia.org/wiki/Jawi Could also be an acronymous of Java Webkits Incubator =) cheers, Bruno Borges William Sobel-2 wrote: On Sep 22, 2008, at 10:14 AM, Janne Jalkanen wrote: Just in case nobody mentioned this to you yet: Olio is the Finnish word for object as in object relational database or object- oriented programming. You may or may not find this suitable. :-) Unfortunately, it also means that there are quite a few Finnish IT companies with the word olio in their name. Also, olio.fi is owned by a Finnish web design company (though they haven't put anything on it yet). Again, this may or may not be suitable. :-/ I vote for Olio. I doubt if we'll find any string of sounds that won't be in use someplace. Apache is widely used for many corporations and this doesn't seem to be an issue. I think the OO relationship is a positive. Best Regards, Will Sobel Visiting Lecturer RADLab - UC Berkeley - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/-DISCUSS--Names-for-the-Web2.0kit-tp19519690p19633425.html Sent from the Apache Incubator - General mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] accept Olio into incubation
+1 (non-binding) I've informed the Wicket team about this incubator request and there is interest in providing a wicket-based implementation (wicket along with differing ORM technologies of course, like JPA and Hibernate; the way I envision it, we'll use profiles in maven to turn on/off different implementations). When do you think it'd be a good time to add implementations to the mix? During incubation? After it graduates? Is there a requirements document or something for applications wishing to implement the Olio example application? On Tue, Sep 23, 2008 at 1:03 PM, Matt Hogstrom [EMAIL PROTECTED] wrote: +1 (binding) Note: I updated the proposal on the Wiki with my normal e-mail account ([EMAIL PROTECTED]) instead of my work e-mail ([EMAIL PROTECTED]) since my mentoring of this project is unrelated to any aspect of my work responsibilities). On Sep 23, 2008, at 10:33 AM, Craig L Russell wrote: Please vote on accepting Olio into incubation. The proposal can be found at: http://wiki.apache.org/incubator/OlioProposal [This proposal was formerly known as Web20Kit] The text of the proposal: OlioProposal Abstract Apache Olio is a web 2.0 toolkit to help developers evaluate the suitability, functionality and performance of various web technologies by implementing a reasonably complex application in several different technologies. Proposal Olio will develop an example application to understand the benefits, performance, and scalability of popular web technologies. Multiple implementations of the application are planned - each providing the same functionality but staying true to the philosophy of its base language/framework. Background Most web 2.0 sites today use open source languages and frameworks such as PHP, Ruby on Rails, and Java EE to develop their applications. Deployments of these applications also use popular open source servers such as Apache httpd, Tomcat, MySQL, Memcache, and Glassfish. Many other servers/technologies such as lighttpd, mogileFS, mongrels, JRuby are also gaining popularity. With the myriad technologies available, it is not easy to understand how they differ, especially in terms of performance and scalability. With varied levels of documentation available for some open source applications, it is also quite difficult for a web 2.0 startup to understand the correct usage of these technologies so that they don't become a bottleneck as their site grows. Rationale Olio is a toolkit that will attempt to address the above issues. What it does Olio defines an example web 2.0 application (the initial implementation uses an events site somewhat like yahoo.com/upcoming) and provides three implementations: PHP, Java EE, and Ruby on Rails. The toolkit will also define ways to drive load against the application in order to measure performance. As developers join the project, they can implement the same application using their favorite web frameworks and compare their implementations to others. What you can learn from it a) Understand how to use various web 2.0 technologies such as AJAX, memcached, mogileFS etc. in the creation of your own application. Use the code in the application to understand the subtle complexities involved and how to get around issues with these technologies. b) Evaluate the differences in the implementations: PHP, Ruby on Rails, Java EE, and other contributed implementations to understand which might best work for your situation. c) Within each language implementation, evaluate different infrastructure technologies by changing the servers used (e.g: apache vs lighttpd, MySQL vs PostgreSQL, Ruby vs Jruby etc.) d) Drive load against the application to evaluate the performance and scalability of the chosen platform. e) Experiment with different algorithms (e.g. memcache locking, a different DB access API) by replacing portions of code in the application. A robust, community-developed standard implementations of a web 2.0 application using different technologies will enable developers to compare and contrast these technologies in a manner that does not exist today. By providing excellent sample implementations of a concrete application that is available to everyone, we will enable faster and easier application development for users. Although we list three implementations in this proposal, we encourage others to come up with many more using other language stacks and/or frameworks e.g. Spring framework, Python etc. Current Status This is a new project with some sample not-ready-for-prime-time code. Meritocracy The initial developers are very familiar with meritocratic open source development, both at Apache and elsewhere. Apache was chosen specifically because the initial developers want to encourage this style of development for the project. Community Olio seeks to create developer and user communities during incubation. Core Developers The initial core developers
Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
I think incubating projects should go through phases. The first phase is to make sure all IP concerns are cleared up. The second phase is where the project exhibits that it gets the Apache way of doing business by doing some internal-only releases (this is where package names would change and stuff of course). The third phase (don't know if any others would be required or not) would be the community building phase. I'd say that projects in phase 1 should not be allowed to do releases (duh). The releases done during phase 2 should be internal-only. The phase 3 releases should be allowed to be full fledged ASF releases. Phase 3 may not be necessary for some projects, if their community is proven to be healthy after phase 2. On Tue, Sep 23, 2008 at 6:15 PM, Doug Cutting [EMAIL PROTECTED] wrote: Jukka Zitting wrote: [ ] +1 Yes, allow extra release distribution channels like the central Maven repository [ ] -1 No, keep the current policy +1 All releases by ASF PMC's should be equal. If the Incubator PMC isn't confident of a release then it shouldn't release it. The release process should not just check legal concerns, but also the quality of the code and its community. A responsible PMC should not release code that sucks or that has a badly flawed community. Doug - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket implementation re: [VOTE] accept Olio into incubation
Craig, Thanks. Where is the code now? Igor Vaynberg (from the Wicket development team) and I (a lowly Wicket user :) are both interested in working on a wicket implementation (hopefully together). If we could see what it currently entails, we may be able to get started. It might be nice if Olio itself could provide some common stuff (language-specific of course) that any implementation would need such as perhaps some Repository/DAO interfaces and their implementations using different technologies (hibernate, jdo, ibatis, jpa, cayenne, etc.). That way, creating an implementation using your web framework of choice could just grab that stuff off the shelf and run with it. If we use common code for some parts of the implementations, then we take that variable out of the equation and we can see how the frameworks themselves stack up against one another. Perhaps even setting up a web services-based implementation of the domain might be a good way to keep it separated. Just a thought. I wouldn't mind helping out on Olio during incubation (and after incubation). I've never worked on an incubating project, but I am a PMC member on Commons and I'm the PMC chair for HiveMind, so I have some experience with the apache way. I'm not currently a member of the Incubator PMC (I think I just have to ask to join, though). Would that help? James On Wed, Sep 24, 2008 at 12:54 AM, Craig L Russell [EMAIL PROTECTED] wrote: Hi James, It's great that Wicket has an interest in Olio. It's probably too late to update the wiki page, but folks reading this thread will see your comments. I'd encourage you to start working on the Wicket impl during incubation. Hopefully once the code arrives it will be a bit more clear what an alternative impl has to do to fit into the structure of Olio. And if it isn't clear, file a JIRA. ;-) Thanks, Craig On Sep 23, 2008, at 5:01 PM, James Carman wrote: +1 (non-binding) I've informed the Wicket team about this incubator request and there is interest in providing a wicket-based implementation (wicket along with differing ORM technologies of course, like JPA and Hibernate; the way I envision it, we'll use profiles in maven to turn on/off different implementations). When do you think it'd be a good time to add implementations to the mix? During incubation? After it graduates? Is there a requirements document or something for applications wishing to implement the Olio example application? On Tue, Sep 23, 2008 at 1:03 PM, Matt Hogstrom [EMAIL PROTECTED] wrote: +1 (binding) Note: I updated the proposal on the Wiki with my normal e-mail account ([EMAIL PROTECTED]) instead of my work e-mail ([EMAIL PROTECTED]) since my mentoring of this project is unrelated to any aspect of my work responsibilities). On Sep 23, 2008, at 10:33 AM, Craig L Russell wrote: Please vote on accepting Olio into incubation. The proposal can be found at: http://wiki.apache.org/incubator/OlioProposal [This proposal was formerly known as Web20Kit] The text of the proposal: OlioProposal Abstract Apache Olio is a web 2.0 toolkit to help developers evaluate the suitability, functionality and performance of various web technologies by implementing a reasonably complex application in several different technologies. Proposal Olio will develop an example application to understand the benefits, performance, and scalability of popular web technologies. Multiple implementations of the application are planned - each providing the same functionality but staying true to the philosophy of its base language/framework. Background Most web 2.0 sites today use open source languages and frameworks such as PHP, Ruby on Rails, and Java EE to develop their applications. Deployments of these applications also use popular open source servers such as Apache httpd, Tomcat, MySQL, Memcache, and Glassfish. Many other servers/technologies such as lighttpd, mogileFS, mongrels, JRuby are also gaining popularity. With the myriad technologies available, it is not easy to understand how they differ, especially in terms of performance and scalability. With varied levels of documentation available for some open source applications, it is also quite difficult for a web 2.0 startup to understand the correct usage of these technologies so that they don't become a bottleneck as their site grows. Rationale Olio is a toolkit that will attempt to address the above issues. What it does Olio defines an example web 2.0 application (the initial implementation uses an events site somewhat like yahoo.com/upcoming) and provides three implementations: PHP, Java EE, and Ruby on Rails. The toolkit will also define ways to drive load against the application in order to measure performance. As developers join the project, they can implement the same application using their favorite web frameworks and compare their implementations to others. What you can learn from
Joining the PMC...
Do I have to actually be an Apache Member to join the Incubator PMC? I'm not currently an ASF member, but I'm interested in helping out with the incubator. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Joining the PMC...
Do I just send a request to the ASF board? On Mon, Sep 29, 2008 at 12:47 PM, Craig L Russell [EMAIL PROTECTED] wrote: Hi James, No, you don't need to be an ASF member to join (but it helps ;-) Interim to becoming an IPMC member, you can help in the incubator just by monitoring and responding to the general at incubator list. Craig On Sep 29, 2008, at 8:57 AM, James Carman wrote: Do I have to actually be an Apache Member to join the Incubator PMC? I'm not currently an ASF member, but I'm interested in helping out with the incubator. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Craig L Russell Architect, Sun Java Enterprise System http://db.apache.org/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL - OpenWebBeans Project Proposal]
A non-disclosure agreement (NDA) is required to be an apache committer? Since when? On Tue, Oct 7, 2008 at 4:48 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote: On Tue, Oct 7, 2008 at 10:40 AM, Gurkan Erdogdu [EMAIL PROTECTED] wrote: How to get or sign this NDA to view current draft spec? Is it required to be part of the EG? no, that is an Apache thing. You need to be committer to sign the NDA. The NDA on the other hand gives you access to TCK etc. In case of WebBeans... this shouldn't be a big deal (TCK) since it is actually Apache 2.0 licensed. When this project is accepted, you will be an Apache committer and we can work on the NDA. @Vote: You asked about the vote, why not planing to start a vote beginning of next week ? This will give some folks some more time to read the proposal etc. No need to rush, isn't it ? -M Gurkan - Original Message From: Matthias Wessendorf [EMAIL PROTECTED] To: general@incubator.apache.org Sent: Monday, October 6, 2008 10:23:22 PM Subject: Re: [PROPOSAL - OpenWebBeans Project Proposal] I am part of the EG, but I can't share the draft PDFs. You need a NDA for that. -M On Mon, Oct 6, 2008 at 8:27 PM, Gurkan Erdogdu [EMAIL PROTECTED] wrote: Hi Kevan, Matthias; The project current code base is in the sourceforge -- http://bigfaces.svn.sourceforge.net/viewvc/bigfaces/webbeansimpl/. I am developing the remaining pieces of the specification continuously. About Implementation : So far, only Web Beans specification that is published is EDR-1, in this EDR-1 there is no API contract of the specification. So when I started to implement the specification, I created my own API. But now, I looked at the http://seamframework.org/WebBeans address and it defines the API contracts and some of the concerns explained in the EDR-1 are changed. I am trying to adapted my implemented API contracts with this unpublished API. I explicitly commented on these changes in the source code. I think there is no so much differences. There are two folder in the implementation, webbeans-api is the API and webbeans-impl is the implementation. All the unit test are contained in the webbeans-impl folder. Thanks; Gurkan - Original Message From: Matthias Wessendorf [EMAIL PROTECTED] To: general@incubator.apache.org Sent: Monday, October 6, 2008 3:34:34 PM Subject: Re: [PROPOSAL - OpenWebBeans Project Proposal] On Mon, Oct 6, 2008 at 2:30 PM, Kevan Miller [EMAIL PROTECTED] wrote: On Oct 3, 2008, at 4:48 PM, Gurkan Erdogdu wrote: Hi to all; I have posted a proposal about the project, named OpenWebBeans. It is in the WIKI, its address is http://wiki.apache.org/incubator/OpenWebBeansProposal I made a few minor editorial updates (spelling/grammar) and one wording change Geronimo will include == Geronimo may include. Can you point us to the current project? I couldn't find it on sourceforge. Last I recall Guice was planning on an Apache licensed WebBeans implementation. Is that still their plan? Any discussions with their project? really ? Interesting. The JBoss WebBeans RI is Apache 2.0 licensed as well (and it looks like their TCK will be as well) See here: http://seamframework.org/WebBeans -Matthias --kevan -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Voting Process About OpenWebBeans Proposal
I'd vote +1 (non-binding) for it. I'd love to be involved no matter where the project lives. On Thu, Oct 16, 2008 at 9:16 AM, Gurkan Erdogdu [EMAIL PROTECTED] wrote: Hi; I am planning to start a vote process again at next monday. Are there still any concerns about the proposal ? Do you think we could start a VOTE process ? Thanks; -- Gurkan Erdogdu http://gurkanerdogdu.blogspot.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accepting OpenWebBeans into the Incubator
+1 (non-binding) On Sun, Oct 19, 2008 at 2:48 PM, Gurkan Erdogdu [EMAIL PROTECTED] wrote: Hi; Incubator PMC, this is the repetition for the [VOTE] process for the OpenWebBeans proposal. If acceptable, please vote on the proposal until 27 Oct. PS : The following fellows voted positively so far; * Niklas Gustavsson +1 (non-binding) * Matt Hogstrom +1 (binding) * Martijn Dashorst +1 (binding) * Niclas Hedhman +1 (binding) Sincerely; Gurkan Erdogdu - Forwarded Message From: Gurkan Erdogdu [EMAIL PROTECTED] To: general@incubator.apache.org Sent: Sunday, October 12, 2008 5:50:15 PM Subject: [VOTE] Accepting OpenWebBeans into the Incubator Incubator PMC, Please vote on accepting the OpenWebBeans project for incubation. The full OpenWebBeans proposal is available at the end of this message and as a wiki page at http://wiki.apache.org/incubator/OpenWebBeansProposal. Here is my +1 = OpenWebBeans, Web Beans Container Implementation = === Abstract === Open Web Beans will be an ASL-licensed implementation of the Web Beans Specification which is defined as JSR-299. . === Proposal === Web Beans specification is an effort for defining stateful, contextual component models and its management for the enterprise applications that run on the Java EE 6 containers. It is a big step that it unifies the EJB (Enterprise Java Beans) and JSF (Java Server Faces) standart component models easily with simplifying the complex programming model from the developer perspective. Currently there is no standard based approach for integrating EJB session beans as a JSF based managed bean. Moreover, EJB does not define any contextual component model. Developer is responsible for managing all the lifecycle of the EJB components. Web Beans provides the management and lifecycle of the components within the container with a standart fashion. It uses the Java 5.0 annotation capability to further easing the configuration efforts. Altough Web Beans simplifies the EJB programming model within the enterprise projects, it could also be used outside of the Java EE containers, such as Apache Tomcat with its powerful component and context model. Open Web Beans Project is responsible for implementing the runtime container contract for the Web Beans specification. Besides the implementation, Open Web Beans 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 defines the JMS (Java Messaging Service) Web Beans Component used for enterprise messaging, Logging Component for logging, Security Component for security etc. === Background === The development of this project is started by the individual developer as an open source project that is hosted on the sourceforge. Using the Open Web Beans project, enterprise developers unifies the EJB and JSF technlogies together easily. Neither of these standarts solves the all problems of the Java EE environment. While the EJB components solves the security, transactions, concurrency and scalability problems, JSF defines the web-tier presentation framework with its graphical component models, events and managed bean facility. Web Beans enables the developers to unify these component models easily within well defined semantics. Applications that uses the Open Web Beans Project may get more advanced context and component model provided by the project. === Rationale === Current Web Beans specificatin is in the EDR (Early Draft Review) level now, and no reference implementation is available yet. Introducing the early implementation of the specification to the enterprise community with using other Apache related projects, such as Open EJB, Open JPA and MyFaces, will attract a diverse community. Moreover, Open Web Beans will work closely with the other Apache projects such that it depends on the Open EJB, Open JPA and My Faces. Moreover, Geronimo may include it as a Web Beans Container when it implements Java EE 6 specification as a runtime environment in which Web Beans executes. Current Web Beans specification may be used in the Java EE 5 environment. Its very powerful type safe and EL component model injection mechanisms and other very useful stuffs could attracts the community that will use it in their current enterprise projects. === Initial Goals === The initial goals of the Open Web Beans Project are * Fully implement the JSR-299 specification. * Attracts a community around the current code base. * Active relationship with the other dependent projects to further develop some useful Web Beans 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
Re: [VOTE] Accepting OpenWebBeans into the Incubator
No worries. It's non-binding anyway. :) On Sun, Oct 19, 2008 at 5:51 PM, Gurkan Erdogdu [EMAIL PROTECTED] wrote: Hey James; Sorry for forgetting to add your vote sending before into the list Thanks for re-vote; Gurkan Erdogdu 2008/10/20 James Carman [EMAIL PROTECTED] +1 (non-binding) On Sun, Oct 19, 2008 at 2:48 PM, Gurkan Erdogdu [EMAIL PROTECTED] wrote: Hi; Incubator PMC, this is the repetition for the [VOTE] process for the OpenWebBeans proposal. If acceptable, please vote on the proposal until 27 Oct. PS : The following fellows voted positively so far; * Niklas Gustavsson +1 (non-binding) * Matt Hogstrom +1 (binding) * Martijn Dashorst +1 (binding) * Niclas Hedhman +1 (binding) Sincerely; Gurkan Erdogdu - Forwarded Message From: Gurkan Erdogdu [EMAIL PROTECTED] To: general@incubator.apache.org Sent: Sunday, October 12, 2008 5:50:15 PM Subject: [VOTE] Accepting OpenWebBeans into the Incubator Incubator PMC, Please vote on accepting the OpenWebBeans project for incubation. The full OpenWebBeans proposal is available at the end of this message and as a wiki page at http://wiki.apache.org/incubator/OpenWebBeansProposal. Here is my +1 = OpenWebBeans, Web Beans Container Implementation = === Abstract === Open Web Beans will be an ASL-licensed implementation of the Web Beans Specification which is defined as JSR-299. . === Proposal === Web Beans specification is an effort for defining stateful, contextual component models and its management for the enterprise applications that run on the Java EE 6 containers. It is a big step that it unifies the EJB (Enterprise Java Beans) and JSF (Java Server Faces) standart component models easily with simplifying the complex programming model from the developer perspective. Currently there is no standard based approach for integrating EJB session beans as a JSF based managed bean. Moreover, EJB does not define any contextual component model. Developer is responsible for managing all the lifecycle of the EJB components. Web Beans provides the management and lifecycle of the components within the container with a standart fashion. It uses the Java 5.0 annotation capability to further easing the configuration efforts. Altough Web Beans simplifies the EJB programming model within the enterprise projects, it could also be used outside of the Java EE containers, such as Apache Tomcat with its powerful component and context model. Open Web Beans Project is responsible for implementing the runtime container contract for the Web Beans specification. Besides the implementation, Open Web Beans 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 defines the JMS (Java Messaging Service) Web Beans Component used for enterprise messaging, Logging Component for logging, Security Component for security etc. === Background === The development of this project is started by the individual developer as an open source project that is hosted on the sourceforge. Using the Open Web Beans project, enterprise developers unifies the EJB and JSF technlogies together easily. Neither of these standarts solves the all problems of the Java EE environment. While the EJB components solves the security, transactions, concurrency and scalability problems, JSF defines the web-tier presentation framework with its graphical component models, events and managed bean facility. Web Beans enables the developers to unify these component models easily within well defined semantics. Applications that uses the Open Web Beans Project may get more advanced context and component model provided by the project. === Rationale === Current Web Beans specificatin is in the EDR (Early Draft Review) level now, and no reference implementation is available yet. Introducing the early implementation of the specification to the enterprise community with using other Apache related projects, such as Open EJB, Open JPA and MyFaces, will attract a diverse community. Moreover, Open Web Beans will work closely with the other Apache projects such that it depends on the Open EJB, Open JPA and My Faces. Moreover, Geronimo may include it as a Web Beans Container when it implements Java EE 6 specification as a runtime environment in which Web Beans executes. Current Web Beans specification may be used in the Java EE 5 environment. Its very powerful type safe and EL component model injection mechanisms and other very useful stuffs could attracts the community that will use it in their current enterprise projects. === Initial Goals === The initial goals of the Open Web Beans Project are * Fully implement the JSR-299 specification. * Attracts a community around the current code base. * Active relationship with the other
Re: Proposed use of org.apache.wiki name space for JSPWiki
On Mon, Feb 2, 2009 at 5:31 PM, Gavin ga...@16degrees.com.au wrote: -Original Message- From: Robert Burrell Donkin [mailto:robertburrelldon...@gmail.com] Sent: Tuesday, 3 February 2009 8:25 AM To: general@incubator.apache.org Subject: Re: Proposed use of org.apache.wiki name space for JSPWiki On Sat, Jan 31, 2009 at 5:26 PM, Craig L Russell craig.russ...@sun.com wrote: The JSPWiki podling has encountered a glitch in plans to change the package name from com.ecyrd.jspwiki (the package name of the donated code base) to org.apache.jspwiki (the original intent). Due to a bug in the Apache Tomcat project, the name org.apache.jspXXX is not usable as a package name. This is documented at https://issues.apache.org/jira/browse/JSPWIKI-465 The direction the team is taking is to use org.apache.wiki as the package name for the project files. You can see the discussion at https://issues.apache.org/jira/browse/JSPWIKI-38 Since this is a change from what most folks would expect and a change from the original intent, I thought I'd see if there were any issues from anyone in the incubator. org.apache.wiki sounds reasonable enough to me (given the context) yeah, or what about org.apache.jwiki ? http://www.jwiki.org/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [vote] Apache Etch 1.0.2-incubating (second attempt)
Don't you usually need 3 +1 binding votes to do a release? On Mar 19, 2009 1:54 PM, James Dixson dixs...@gmail.com wrote: So far we are at +2 If we do not get anymore votes before Monday (23-Mar), I would like to go ahead and declare victory and move forward with the release. -- james On Mar 12, 2009, at 8:54 AM, James Dixson wrote: Here are new package versions for apache-etc...
Re: [vote] Apache Etch 1.0.2-incubating (second attempt)
Actually, the 3 vote minimum is required. If you look here: http://www.apache.org/foundation/voting.html It says the 'minimum of three +1 votes' rule is universal. On Thu, Mar 19, 2009 at 2:50 PM, Kevan Miller kevan.mil...@gmail.com wrote: On Mar 19, 2009, at 2:41 PM, James Carman wrote: Don't you usually need 3 +1 binding votes to do a release? Yes. I'd hope that there were some additional mentor votes on the PPMC vote. Anyways, here's my +1. I looked at source, and generated binaries. I didn't try to build... --kevan - 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: photark project (was: Re: Stepping down as mentor for PhotArk)
I wouldn't recommend using these tools for your community discussions, though. On Sun, Aug 2, 2009 at 2:03 PM, Luciano Resendeluckbr1...@gmail.com wrote: On Sat, Aug 1, 2009 at 4:35 PM, Angela Cymbalaka.cymba...@nechtan.org wrote: I've been spending more than my fair share of time on Facebook lately. Are we allowed to set up a Facebook page for the project? Just not sure since we are in incubation? What about a Twitter feed? Can we do those without breaking any of the incubation rules? I can do them if I know what my guidelines are... I don' t think there are specific guidelines/policies around Facebook/Twitter usage, but Apache have been using this for events advertisement and infrastructure notifications etc so it should be ok for us to use If you do this, please inform the PhotArk PPMC (via private list) of the credentials to manage the accounts. -- Luciano Resende Apache Tuscany, Apache PhotArk http://people.apache.org/~lresende http://lresende.blogspot.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
Re: Lokahi scavengers alert (was Re: [VOTE] Mothball/Pause Lokahi)
On Wed, Aug 12, 2009 at 3:57 AM, Martijn Dashorstmartijn.dasho...@gmail.com wrote: Is there something for projects to cherrypick/scavenge? E.g. some code that can be merged into Tomcat, commons, or any of the web frameworks that are around? Is this something we could send to all PMCs for any podling that is going to be paused/mothballed? You mean like a source code garage sale announcement? :) Good idea! A lot of PMCs might not know what these podlings do (or that they're being retired for that matter). - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: Biological Object Model Project
I meant biological object model project. Sorry. -Original Message- From: James Carman [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 07, 2005 6:35 PM To: general@incubator.apache.org Subject: Biological Object Model Project All, I would like to start a biological object model process (I need to come up with a catchier name) and I think ASF would be a great place for it. I currently work with a product called GKP (Genomics Knowledge Platform) from a company called Xteric and it works fairly well, but it is not open source. It's tough to get grant money from the government for software development if you're using something that's proprietary and not open source. You can't exactly tell a university that they have to spend $1M on a software package if they wish to use it for research. Anyway, what is needed in the Genomics/Bioinformatics world is a common, standardized, open source object model for us to develop applications against. I understand that I'm supposed to have a working codebase, but this is still a vision for me. However, if we started a project, I think we could get some real experts (bioinformaticians) to contribute and work towards developing a standard platform. Any thoughts? James Carman - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Biological Object Model Project
From what I understand, the BioJava project doesn't really provide persistence for biological objects, which is something that I would want in a model/platform. My idea is to use something like Hibernate or JDO to actually persist the data. Also, the last recent update for BioJava was from May 2004. I would think that a platform should allow you to store your objects into a persistent storage mechanism (RDBMS). Once you have a persistable model in place, then you write utilities which can operate on it. Granted, I haven't used BioJava that much. I'm just going by what I see from the JavaDocs and I could be very wrong. -Original Message- From: Jukka Zitting [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 08, 2005 2:10 AM To: general@incubator.apache.org Subject: Re: Biological Object Model Project Hi, James Carman wrote: I would like to start a biological object model process (I need to come up with a catchier name) and I think ASF would be a great place for it. Have you looked at the Open Bioinformatics Foundation (http://www.open-bio.org/)? They are not ASF, but they have a working, actively used and evolving codebase that already forms a de-facto standard platform for open source bioinformatics. BR, Jukka Zitting - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Biological Object Model Project
Sanjiva, I'm glad you like the idea. I think there is a need for something like this in the bioinformatics community. Well, I could start modeling some classes that I'm somewhat familiar with. Unfortunately, though, I'm not a bioinformatician, so I'm not exactly the person who should be doing the actual domain modeling. What I (and many others at ASF) can bring to the table is the infrastructure which allows the objects to be stored/retrieved. Maybe I could try to recruit some help from some domain experts (bioinformaticians) to start developing the model. Then, we could bring some subset of the finished product in as an ASF incubator project. How does that sound? I was really just wanting to figure out if ASF would be willing to host a project such as this one. James -Original Message- From: Sanjiva Weerawarana [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 08, 2005 7:19 PM To: general@incubator.apache.org Subject: Re: Biological Object Model Project IMO its a great idea (assuming nothing like that exists) but how can ASF help you given that the incubator is meant to bring in existing projects with working code rather than ideas? Sanjiva. On Tue, 2005-06-07 at 18:35 -0400, James Carman wrote: All, I would like to start a biological object model process (I need to come up with a catchier name) and I think ASF would be a great place for it. I currently work with a product called GKP (Genomics Knowledge Platform) from a company called Xteric and it works fairly well, but it is not open source. It's tough to get grant money from the government for software development if you're using something that's proprietary and not open source. You can't exactly tell a university that they have to spend $1M on a software package if they wish to use it for research. Anyway, what is needed in the Genomics/Bioinformatics world is a common, standardized, open source object model for us to develop applications against. I understand that I'm supposed to have a working codebase, but this is still a vision for me. However, if we started a project, I think we could get some real experts (bioinformaticians) to contribute and work towards developing a standard platform. Any thoughts? James Carman - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Biological Object Model Project
Niclas, Thanks for your reply. I think I am going to go ahead and start modeling some stuff and get a codebase together. Then, I'll have a more legitimate shot at getting some support and maybe approval for an incubator project. BioJava doesn't exactly exhibit domain-driven design which is what I would like to have this new project use. I want to be able to start fresh without all of the limitations of an existing model with software already written against it. James -Original Message- From: Niclas Hedhman [mailto:[EMAIL PROTECTED] Sent: Thursday, June 09, 2005 4:39 AM To: general@incubator.apache.org Cc: James Carman Subject: Re: Biological Object Model Project On Thursday 09 June 2005 08:12, James Carman wrote: I was really just wanting to figure out if ASF would be willing to host a project such as this one. Unfortunately, ASF does not really operate like this. First get at least some source in order, then gather some support from both within and outside of ASF, then come with the proposal to the Incubator. AFAIK, that is how things are done around here. Furthermore, if you feel the JavaBio project is lacking something important, why do you not just go there and implement it? I am sure they would be happy for new contributors. Cheers Niclas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: a few steps before approving a project
So, does that mean that Jakarta Commons Proxy will have to go through the Incubator? Right now, it's a commons sandbox project, so it's not officially supported. The code first lived in my syringe project I created over at java.net. It was all developed by me under the Apache License 2.0. Will Commons Proxy have to go through the Incubator to get into commons proper? Or, should it be in the incubator now? -Original Message- From: Sam Ruby [mailto:[EMAIL PROTECTED] Sent: Thursday, September 01, 2005 9:08 AM To: general@incubator.apache.org Subject: Re: a few steps before approving a project Sanjiva Weerawarana wrote: On Wed, 2005-08-31 at 11:43 -0700, Justin Erenkrantz wrote: The Incubator's charter from the board says: http://incubator.apache.org/resolution.html RESOLVED, that the Apache Incubator PMC be and hereby is responsible for the acceptance and oversight of new products submitted or proposed to become part of the Foundation; and be it further Previously, the board had to deal with this directly. The board delegated this to the Incubator PMC. Whoa. I had understood this as incoming external projects instead of any in-bred ones. So by your (and Jim's) interpretation, we did Axis2 wrong?? We started that with people who were Axis committers and started with no external code contrib from anyone. We didn't go thru the incubator - just created an SVN tree and started hacking. Are you guys saying that that was wrong and that the incubator had to get involved to teach us the Apache way? Huh? Can we get board clarification on this please? Reading the above resolution that is by no means clear, at least to me. If the SVN tree was always on ASF infrastructure, the code was always under the Apache License, and the committers were all ASF committers, then no trip through the incubator is necessary. If any ONE of these things are not true (example: code on CodeHaus created by ASF committers with Apache license), then incubator needs to be involved to ensure that there is a proper audit trail. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Commons Proxy Incubation...
Sorry to have hijacked another thread for this discussion, but the contents of that thread brought about the question. Anyway, here's the situation. 1. I developed all of the code myself while trying to come up with ideas of how we could redesign Jakarta HiveMind to make it lend itself more to configuration by hand (less XML good). 2. My employer, a company solely owned by me (I'm an independent consultant), does not have a problem with the code being granted to ASF. If you guys need a grant signed and faxed in, I can do that quite easily. 3. Yes, I am an Apache Committer ([EMAIL PROTECTED]) with individual CLA on file. So, should we officially go through the incubator just to make this project legitimate? I apologize for not doing so in the first place, but the way we describe the sandbox makes it sound like a very informal place for us committers to toss around ideas/thoughts. James
RE: Commons Proxy Incubation...
Where do I fax the form? There are no instructions on it. -Original Message- From: Justin Erenkrantz [mailto:[EMAIL PROTECTED] Sent: Thursday, September 01, 2005 5:07 PM To: general@incubator.apache.org Subject: Re: Commons Proxy Incubation... --On September 1, 2005 4:52:57 PM -0400 James Carman [EMAIL PROTECTED] wrote: Sorry to have hijacked another thread for this discussion, but the contents of that thread brought about the question. Anyway, here's the situation. 1.I developed all of the code myself while trying to come up with ideas of how we could redesign Jakarta HiveMind to make it lend itself more to configuration by hand (less XML good). 2.My employer, a company solely owned by me (I'm an independent consultant), does not have a problem with the code being granted to ASF. If you guys need a grant signed and faxed in, I can do that quite easily. 3.Yes, I am an Apache Committer ([EMAIL PROTECTED]) with individual CLA on file. So, should we officially go through the incubator just to make this project legitimate? I apologize for not doing so in the first place, but the way we describe the sandbox makes it sound like a very informal place for us committers to toss around ideas/thoughts. I would follow this set of guidelines: http://svn.apache.org/repos/asf/incubator/public/trunk/site-author/projects /ip-clearance-template.html Based upon your description, it should be as simple as filling out this form. (And sending in the software-grant.txt form.) You might find wss4j a good example of a filled out IP clearance form: http://svn.apache.org/repos/asf/incubator/public/trunk/site-author/projects /wss4j.cwiki HTH. -- justin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Commons Proxy Incubation...
I faxed it the other day. Will I get some sort of confirmation about the software grant being filed? -Original Message- From: Justin Erenkrantz [mailto:[EMAIL PROTECTED] Sent: Thursday, September 08, 2005 11:50 AM To: general@incubator.apache.org Subject: RE: Commons Proxy Incubation... --On September 7, 2005 11:16:37 PM -0400 James Carman [EMAIL PROTECTED] wrote: Where do I fax the form? There are no instructions on it. Hmm. Good point. You fax it to the same number as the CLAs, which says: If you have not already done so, please complete and send an original signed Agreement to The Apache Software Foundation, 1901 Munsey Drive, Forest Hill, MD 21050-2747, U.S.A. If necessary, you may send it by facsimile to the Foundation at +1-410-803-2258. Please read this document carefully before signing and keep a copy for your records. Thanks. -- justin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Starting a java specs project
Why not do like we do with the commons? spec-javamail -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Friday, December 30, 2005 9:08 AM To: general@incubator.apache.org Cc: [EMAIL PROTECTED] Subject: Re: Starting a java specs project On 12/27/05, Hiram Chirino [EMAIL PROTECTED] wrote: Hi, I think this would be great! I know it's silly, but I get annoyed at the fact that many of the J2EE spec jars that I use from apache have geronimo- in the jar name but It's just the ASL 2.0 spec jars that I'm using and not really a geronimo implementation. In general, I think that this would make a good TLP since it would provide a good area for cross project involvement. [presuming it was stored at Jakarta Specs] Do you think they should be apache- or jakarta-, or either would be fine? Would 'jakarta-spec-javamail' be too much of a mouthful? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Thoughts on Umbrellas, Federations, and Communication
I think that introducing ontology into the mailing lists would be a good idea. It'd be nice to know, for instance, that there is an O/R mapping project (or two as it seems: JPA and Cayenne) being added to the incubator if I'm an Apache DB committer. -Original Message- From: Noel J. Bergman [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 08, 2006 10:34 AM To: general@incubator.apache.org Subject: Thoughts on Umbrellas, Federations, and Communication Daniel John Debrunner wrote: robert burrell donkin wrote: the only caveat being DB is feeling a little bit umbrella-ish these days. I've seen this comment a couple of times in the last week or so, but I don't really understand what it's trying to say. What makes an Apache project umbrella-ish? ASF projects are supposed to be about a community managing a project. So the warning signs include large disjoint communities, e.g., Jakarta, the old XML project (which, itself, was a Jakarta spin-off), etc. So, good project boundaries are considered to be administrative, rather than ontological. On the other hand, there are good reasons for considering ontological domains. And as we disband umbrella projects, we have been losing communication within ontological domains that cross the administative (TLP) boundaries. One of thing things that the we need to look at is how to improve communication across projects. Perhaps having some ontological mailing lists would be part of a solution. What ideas and views do others have? --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CCLA's and SGA's
The foundation doesn't require CCLAs (they're a good CYA for the employees though) but we do require ICLAs. On Sunday, February 8, 2015, John D. Ament johndam...@apache.org wrote: All, Just wanted to confirm with others. If a company is donating a new project to the ASF, a CCLA (or multiple ICLAs) are required to allow contributors from that project to continue on in Apache, as well as an SGA to allow the company to transfer the existing software to the ASF. Basically, the CLA is for future work, SGA is for existing work. Let me know if this is a better question for legal. John
Software Grants for GitHub Projects...
Is there a standard within the incubator about how we go about getting the appropriate forms filled out when we want to incubate a project from GitHub? GitHub fosters a sort of fly-by contribution model (and that's a good thing), but it makes donating the code a bit troublesome, because we need to make sure that all (to a certain degree?) of the contributors do, in fact want to donate the code they contributed to the foundation. Note that this problem isn't necessarily unique to GitHub, but Git itself somewhat highlights the issue because contributions from outside parties (pull requests) do maintain metadata about their original authors. With SVN, typically someone with karma has to do the commit and it gets tagged with their identity, so the audit trail goes cold (comments can contain attributions, but that's hard to report on). Anyway, just looking for some guidance here. We are trying to move TinkerPop forward and how exactly we go about getting the forms filled out properly is somewhat of a blocker. Thanks, James Carman, Assistant Secretary Apache Software Foundation - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Software Grants for GitHub Projects...
Are there guidelines for these usual considerations? On Saturday, January 31, 2015, Benson Margulies bimargul...@gmail.com wrote: On Sat, Jan 31, 2015 at 8:44 AM, James Carman ja...@carmanconsulting.com javascript:; wrote: Is there a standard within the incubator about how we go about getting the appropriate forms filled out when we want to incubate a project from GitHub? GitHub fosters a sort of fly-by contribution model (and that's a good thing), but it makes donating the code a bit troublesome, because we need to make sure that all (to a certain degree?) of the contributors do, in fact want to donate the code they contributed to the foundation. Simple answer: no. It is up to you to get ICLA/CCLA/SGA as appropriate for all contributors based on the usual considerations of contribution size, copyright ownership, and provenance clarity. if you have some stray commits that you can't cover, you can either reimplement, or make an argument that are below the threshold of concern. The github metadata helps a bit, but since you have no guarantee that the committer is the author, there's no possible way to see this as automated. The fact that code is published under the AL does _not_ make it automatically code that you can pull in no matter what else. We require a positive intent to contribute the code to the foundation. Note that this problem isn't necessarily unique to GitHub, but Git itself somewhat highlights the issue because contributions from outside parties (pull requests) do maintain metadata about their original authors. With SVN, typically someone with karma has to do the commit and it gets tagged with their identity, so the audit trail goes cold (comments can contain attributions, but that's hard to report on). Anyway, just looking for some guidance here. We are trying to move TinkerPop forward and how exactly we go about getting the forms filled out properly is somewhat of a blocker. Thanks, James Carman, Assistant Secretary Apache Software Foundation - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org javascript:; For additional commands, e-mail: general-h...@incubator.apache.org javascript:; - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org javascript:; For additional commands, e-mail: general-h...@incubator.apache.org javascript:;
Re: [Groovy] Next steps...
Bertrand, It took me a second, but I think I found some threads of interest: https://mail-search.apache.org/members/private-arch/board/201502.mbox/%3CCABD8fLVxK8jRT-Rdut9xC2RnHmQ4v9yywe4owNf=98ghdyk...@mail.gmail.com%3E https://mail-search.apache.org/members/private-arch/operations/201501.mbox/%3cc149fc5f-04ff-41ec-b741-f7958357a...@oracle.com%3E http://mail-archives.apache.org/mod_mbox/incubator-general/201501.mbox/%3CCALhtWke4LnWMv1zf8cy3GP3prp-r91WAEe2xi_FAuS=olmh...@mail.gmail.com%3E As you can see, we (by that I probably mean me) caused somewhat of a dust-up wrt TinkerPop's grant to the ASF. James On Thu, Mar 26, 2015 at 7:10 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: On Thu, Mar 26, 2015 at 12:03 PM, James Carman ja...@carmanconsulting.com wrote: We need to make sure we get these guidelines nailed down, because that is not the advice we got when doing Tinker pop Do you have archive links to the relevant discussions? -Bertrand - 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: [Groovy] Next steps...
Emmanuel, I apologize for hijacking your thread. Let me part (and create a new thread) by saying Welcome, Groovy! James On Thu, Mar 26, 2015 at 7:45 AM, James Carman ja...@carmanconsulting.com wrote: Bertrand, It took me a second, but I think I found some threads of interest: https://mail-search.apache.org/members/private-arch/board/201502.mbox/%3CCABD8fLVxK8jRT-Rdut9xC2RnHmQ4v9yywe4owNf=98ghdyk...@mail.gmail.com%3E https://mail-search.apache.org/members/private-arch/operations/201501.mbox/%3cc149fc5f-04ff-41ec-b741-f7958357a...@oracle.com%3E http://mail-archives.apache.org/mod_mbox/incubator-general/201501.mbox/%3CCALhtWke4LnWMv1zf8cy3GP3prp-r91WAEe2xi_FAuS=olmh...@mail.gmail.com%3E As you can see, we (by that I probably mean me) caused somewhat of a dust-up wrt TinkerPop's grant to the ASF. James On Thu, Mar 26, 2015 at 7:10 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: On Thu, Mar 26, 2015 at 12:03 PM, James Carman ja...@carmanconsulting.com wrote: We need to make sure we get these guidelines nailed down, because that is not the advice we got when doing Tinker pop Do you have archive links to the relevant discussions? -Bertrand - 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: ICLA/CCLA/SGA guidelines for GitHub or multi-entity projects was: [Groovy] Next steps...
Let's continue here. It seems there is some confusion around this particular subject, because I don't know that we really reached a point where we said this is what we're SUPPOSED to do in this situation with TinkerPop. We just did what we thought was best at the time. It would be good to have at least some codified guidelines somewhere on a wiki page or something that will help newly-incubating projects in similar situations. Since I do some assistance with secretary@, I don't mind helping with the documentation. I will be one of the main ones interested in said guidelines. :) On Thu, Mar 26, 2015 at 7:54 AM, James Carman ja...@carmanconsulting.com wrote: Emmanuel, I apologize for hijacking your thread. Let me part (and create a new thread) by saying Welcome, Groovy! James On Thu, Mar 26, 2015 at 7:45 AM, James Carman ja...@carmanconsulting.com wrote: Bertrand, It took me a second, but I think I found some threads of interest: https://mail-search.apache.org/members/private-arch/board/201502.mbox/%3CCABD8fLVxK8jRT-Rdut9xC2RnHmQ4v9yywe4owNf=98ghdyk...@mail.gmail.com%3E https://mail-search.apache.org/members/private-arch/operations/201501.mbox/%3cc149fc5f-04ff-41ec-b741-f7958357a...@oracle.com%3E http://mail-archives.apache.org/mod_mbox/incubator-general/201501.mbox/%3CCALhtWke4LnWMv1zf8cy3GP3prp-r91WAEe2xi_FAuS=olmh...@mail.gmail.com%3E As you can see, we (by that I probably mean me) caused somewhat of a dust-up wrt TinkerPop's grant to the ASF. James On Thu, Mar 26, 2015 at 7:10 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: On Thu, Mar 26, 2015 at 12:03 PM, James Carman ja...@carmanconsulting.com wrote: We need to make sure we get these guidelines nailed down, because that is not the advice we got when doing Tinker pop Do you have archive links to the relevant discussions? -Bertrand - 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: [Groovy] Next steps...
We need to make sure we get these guidelines nailed down, because that is not the advice we got when doing Tinker pop. Just seems like a very similar situation. No one entity owns groovy. This is also a very likely situation for us to encounter in the future, especially since two of the major open source homes are shutting down. On Thursday, March 26, 2015, Jim Jagielski j...@jagunet.com wrote: You could sign it on behalf of the Groovy Core team On Mar 26, 2015, at 4:44 AM, Guillaume Laforge glafo...@gmail.com javascript:; wrote: Me as the lead of the project? But I can't say I have more rights than others. Who has more rights than others? is it in terms of number of commits? lines contributed? On Thu, Mar 26, 2015 at 9:40 AM, Bertrand Delacretaz bdelacre...@apache.org javascript:; wrote: Hi, On Thu, Mar 26, 2015 at 9:35 AM, Guillaume Laforge glafo...@gmail.com javascript:; wrote: Who should be signing that grant?.. Paul asked the same question in https://issues.apache.org/jira/browse/INFRA-9341 - I think that's a question for the Groovy team, from the ASF side it's whomever has sufficient rights to contribute the software source code and other related intellectual property who can sign. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org javascript:; For additional commands, e-mail: general-h...@incubator.apache.org javascript:; -- Guillaume Laforge Groovy Project Manager Blog: http://glaforge.appspot.com/ Social: @glaforge http://twitter.com/glaforge / Google+ https://plus.google.com/u/0/114130972232398734985/posts - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org javascript:; For additional commands, e-mail: general-h...@incubator.apache.org javascript:;
Re: ICLA/CCLA/SGA guidelines for GitHub or multi-entity projects was: [Groovy] Next steps...
On Thu, Mar 26, 2015 at 8:22 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: My view is that -All committers need an iCLA I think that we can agree upon and nobody is refuting that. -Software that comes from outside the ASF needs to come with a software grant This is the sticking point. How many grants do we need? Who files them? Can one person file one and say I am speaking on behalf of the entire team? -cCLA is between people and their employers, the ASF only stores them Again, I don't think this is under review either. Perhaps I should have not included them in the title, but the guidelines I'm asking for need to include all of these documents. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: ICLA/CCLA/SGA guidelines for GitHub or multi-entity projects was: [Groovy] Next steps...
I really have no opinion on the matter (IANAL). I'm just a virtual paper pusher, but I did want to have a clear understanding of the requirements so that when folks ask us on secretary@, we can guide them to the right place or give them the right advice. On Thu, Mar 26, 2015 at 9:43 AM, Guillaume Laforge glafo...@gmail.com wrote: So, in summary, can we all agree that I (Groovy projet lead / representative) can fill in the form, and say on behalf of the Groovy community, I grant the rights to the ASF? On Thu, Mar 26, 2015 at 2:31 PM, Emmanuel Lécharny elecha...@gmail.com wrote: I think we are going a bit too far here. Groovy has been under the AL 2.0 license since it moves from BSD (back in 2003). AL 2.0 says : Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the Work and such Derivative Works in Source or Object form. My understanding is that any groovy contributor, including the 5 initial commiters, can grant the existing code base to The ASF, per the AL 2.0 license. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Guillaume Laforge Groovy Project Manager Blog: http://glaforge.appspot.com/ Social: @glaforge http://twitter.com/glaforge / Google+ https://plus.google.com/u/0/114130972232398734985/posts - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: ICLA/CCLA/SGA guidelines for GitHub or multi-entity projects was: [Groovy] Next steps...
And that covers us from a legal standpoint? Is there anything special' about this situation that makes this appropriate? On Thu, Mar 26, 2015 at 10:19 AM, Jim Jagielski j...@jagunet.com wrote: There is no official, legal entity which can make the actual transfer. When we created the ASF, out of the Apache Group, all members of the Apache Group signed the xfer which amounted to the SGA at the time. For Groovy, it is sufficient for G to sign on behalf of the Groovy Core Team. If we could get the initial committers (who ARE the Core team) to also sign, that would be even better. - 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: ICLA/CCLA/SGA guidelines for GitHub or multi-entity projects was: [Groovy] Next steps...
On Thu, Mar 26, 2015 at 10:51 AM, Marvin Humphrey mar...@rectangular.com wrote: If you have a codebase which was not previously under the ALv2 -- say it was either proprietary or available under a different open source license -- then the Software Grant is hugely important from a legal standpoint. You have to get every last copyright owner to sign it, and if you can't get them all on board you have a mess on your hands that will have to be dealt with. In contrast, from a legal standpoint, a signed Software Grant doesn't change much when the codebase is already under the ALv2. (Quite possibly it has zero effect but I'd need to ask a lawyer about the text of the Software Grant form to confirm that.) Separate from the legal aspect, we have a social tradition at Apache of only accepting voluntary contributions. This prevents social disharmony if somebody doesn't want their contribution to go to a project hosted at the ASF. For Groovy, I agree with Benson. We already have sufficient informal evidence that the Groovy community at large has granted social approval for the move to Apache. The software grant does not change much about the legal status of the codebase. Let's not get hung up on who has to sign it. Right, but this thread (renamed) isn't about Groovy. What I was trying to do is tease out more information about these sorts of situations, so that we can maybe put together some clear documentation. If that documentation says when this situation comes up, please ask for help as they need to be evaluated on a case-by-case basis, then that's fine. If this were cut and dry, we probably wouldn't be 18 messages deep into this thread. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Accept Geode into the Apache Incubator
+1 On Mon, Apr 20, 2015 at 12:09 PM Henry Saputra henry.sapu...@gmail.com wrote: +1 (binding) On Sun, Apr 19, 2015 at 10:46 PM, Roman Shaposhnik r...@apache.org wrote: Following the discussion earlier in the thread: http://s.apache.org/Oxt I would like to call a VOTE for accepting Geode as a new incubator project. The proposal is available at: https://wiki.apache.org/incubator/GeodeProposal and is also included at the bottom of this email. Vote is open until at least Sunday, 26 April 2015, 23:59:00 PST [ ] +1 accept Geode in the Incubator [ ] ±0 [ ] -1 because... Thanks, Roman. == Abstract == Geode is a data management platform that provides real-time, consistent access to data-intensive applications throughout widely distributed cloud architectures. Geode pools memory (along with CPU, network and optionally local disk) across multiple processes to manage application objects and behavior. It uses dynamic replication and data partitioning techniques for high availability, improved performance, scalability, and fault tolerance. Geode is both a distributed data container and an in-memory data management system providing reliable asynchronous event notifications and guaranteed message delivery. == Proposal == The goal of this proposal is to bring the core of Pivotal Software, Inc.’s (Pivotal) Pivotal GemFireⓇ codebase into the Apache Software Foundation (ASF) in order to build a vibrant, diverse and self-governed open source community around the technology. Pivotal will continue to market and sell Pivotal GemFire based on Geode. Geode and Pivotal GemFire will be managed separately. This proposal covers the Geode source code (mainly written in Java), Geode documentation and other materials currently available on GitHub. While Geode is our primary choice for a name of the project, in order to facilitate PODLINGNAMESEARCH we have come up with two alternatives: * Haptic * FIG == Background == GemFire is an extremely mature and robust product that can trace its legacy all the way back to one of the first Object Databases for Smalltalk: GemStone. The GemFire code base has been maintained by the same group of engineers as a closed source project. Because of that, even though the engineers behind GemFire are the de-facto knowledge leaders for distributed in-memory management, they have had little exposure to the open source governance process.The original company developing GemStone and GemFire was acquired by VMWare in 2010 and later spun off as part of Pivotal Software in 2013. Today GemFire is used by over 600 enterprise customers. An example deployment includes China National Railways that uses Pivotal GemFire to run railway ticketing for the entire country of China with a 10 node cluster that manages 2 gigabytes hot data in memory, and 10 backup nodes for high availability and elastic scale. == Rationale == Modern-day data management architectures require a robust in-memory data grid solution to handle a variety of use cases, ranging from enterprise-wide caching to real-time transactional applications at scale. In addition, as memory size and network bandwidth growth continues to outpace those of disk, the importance of managing large pools of RAM at scale increases. It is essential to innovate at the same pace and Pivotal strongly believes that in the Big Data space, this can be optimally achieved through a vibrant, diverse, self-governed community collectively innovating around a single codebase while at the same time cross-pollinating with various other data management communities. ASF is the ideal place to meet these ambitious goals. == Initial Goals == Our initial goals are to bring Geode into the ASF, transition internal engineering processes into the open, and foster a collaborative development model according to the Apache Way. Pivotal plans to develop new functionality in an open, community-driven way. To get there, the existing internal build, test and release processes will be refactored to support open development. == Current Status == Currently, the project code base is licensed for evaluation purposes and is available for download from Pivotal.io (https://network.pivotal.io/products/project-geode). The documentation and wiki pages are available as public GitHub repositories under Project Geode organization on GitHub (https://github.com/project-geode). Although Pivotal GemFire was developed as a proprietary, closed-source product, the internal engineering practices adopted by the development team lend themselves well to an open, collaborative and meritocratic environment. The Pivotal GemFire team has always focused on building a robust end user community of paying and non-paying customers. The existing documentation along with StackOverflow and other similar forums are expected to
Re: [DISCUSS] Whimsy PMC
On Thu, Apr 23, 2015 at 2:47 PM Sam Ruby ru...@intertwingly.net Anyone who is so inclined is welcome to edit the proposal directly. No urgency or timeframe in mind (other than preferably starting sometime in 2015ish). My current thinking is to follow in Steve's footprints and go directly to TLP, but I'm starting a discussion here (in Incubator) to see if there are any other thoughts on the matter. Added myself as an initial committer, in case I want to jump in and get my hands dirty. :)
