Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 76652 invoked from network); 6 Jan 2002 23:43:44 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 6 Jan 2002 23:43:44 -0000 Received: (qmail 24422 invoked by uid 97); 6 Jan 2002 23:43:47 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 24406 invoked by uid 97); 6 Jan 2002 23:43:47 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 24395 invoked from network); 6 Jan 2002 23:43:46 -0000 Message-ID: <01bb01c1970c$20b32e60$c77ba8c0@frmt1.sfba.home.com> From: "Martin Cooper" To: "Jakarta Commons Developers List" References: Subject: Re: Commons Validator Packaging/Content Date: Sun, 6 Jan 2002 15:44:47 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Jon, You make some good points here, but I'd like to add a different perspective on what you are seeing. Something that has been nagging at me as I try to keep up with the ongoing discussions on the 'general' list is the talk about whether or not Jakarta is too big. For people like yourself, who have been around Jakarta-land for a long time and watched it grow, Jakarta might not seem all that big, since you've incrementally built up a knowledge of what's going on across the span of the project. For some of us who are newer to Jakarta, it seems pretty darned big. Worse, looking at the individual descriptions of the subprojects doesn't give anything near a complete picture. For example, I can look at what Turbine is and not realise that Torque and Fulcrum are usable independently. And I had no idea that there was a thing called Intake. Since I, for one, don't have the bandwidth to keep up with all the different pieces of all the different projects, I have to rely on others, such as yourself, to volunteer information where appropriate. (And I greatly appreciate those of you who do that for us.) A good time to have mentioned Intake on this list would have been last month, when we had a discussion, and a vote, about bringing David's validation framework into the fold. You must have at least tracked that discussion, since you posted to it, but neither you nor anyone else mentioned Intake at that time. So I would ask you to consider that duplication is not always willful divergence from existing functionality, but that, given the size of Jakarta and the broad functionality implemented by some of the subprojects, it can easily happen as a result of incomplete knowledge of what all we already have in our fold. -- Martin Cooper ----- Original Message ----- From: "Jon Scott Stevens" To: "Jakarta Commons Developers List" Cc: Sent: Sunday, January 06, 2002 2:15 PM Subject: Re: Commons Validator Packaging/Content > on 1/6/02 1:45 PM, "Sam Ruby" wrote: > > > Jon, I presume that you are talking about the subject, and not the text you > > are quoting. In any case, a framework independent validator seems to me to > > be valuable a reusable component. If one or both can't be restructed to be > > framework independent, then that would seem to be a reasonable explanation > > for the duplication. If both can, then merging of the best of both here in > > commons would seem to be the wisest path. > > I don't see why the basis isn't Intake. Why not work to move Intake to > commons and then work towards a framework independent implementation in > Commons? > > Of course it is easier to start from scratch to invent yet another > validation framework. This is where I see another failure of Jakarta. People > only go with the easiest route without any concern about the long term mess > they are making. > > I feel like Jakarta is just going down this path of having a bazillion > different implementations and versions of the same thing and it is only > getting worse. Commons was supposed to help clean that up by providing a > central location, however all I see is it making it worse because people are > just re-inventing what already exists in other projects instead of using > existing projects as the basis. > > A perfect example of this recently was the discussion about Torque. Hey, > Torque exists, but it is *easier* to re-invent it rather than simply spend > the time to figure it out, understand it and move it to commons (or a top > level project). > > I'm starting to realize that Jakarta has grown to becoming a place where > people only scratch their own itches and I agree that that is the basis for > open source. However, we have no overall direction. We all have our own > opinions and spend days and days discussing them and when it comes down to > putting code into CVS, people do whatever they want anyway because there is > no set of checks and balances to put some sort of higher level control over > things. > > In Java Apache, these issues never came up because there were only a few > projects and a few people expressing their opinions. Now, Jakarta has grown > into literally hundreds of people expressing their opinions and doing what > they want. Commons has become an area where people have a free CVS commit > tree to put whatever they want into it, which is fine, however these people > doing the commits haven't spent the time to do things as simple as figuring > out what the proper way to format code according to the Jakarta rules. > > People keep saying that Jakarta isn't broken. Well, if it isn't broken, then > how come we have so many people doing their own thing and not working > together? Jakarta is supposed to be a group collective, however it is > becoming nothing more than another Sourceforge. > > -jon > > > -- > To unsubscribe, e-mail: > For additional commands, e-mail: > -- To unsubscribe, e-mail: For additional commands, e-mail: