commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Winterfeldt <dwinterfe...@yahoo.com>
Subject RE: Commons Validator Packaging/Content
Date Mon, 07 Jan 2002 02:09:27 GMT
The Validator's core validation has been stand-alone
and independent of Struts for about 6 months when it
was refactored to completely decouple it from Struts. 
The project itself is over a year old and was based on
production code that is even older.  So this code has
been in production for a while.  Not as long as Intake
apparently, but this is the first time I've ever heard
about Intake.  Which is one reason why we wanted to
move the Validator to Commons so others could use it
and work on it.  Nothing is perfect, but the group can
work on fixing and/or adding functionality to the
project.  And there can always be more than one
validation framework.

David

--- Paulo Gaspar <paulo.gaspar@krankikom.de> wrote:
> > -----Original Message-----
> > From: Jon Scott Stevens [mailto:jon@latchkey.com]
> > Sent: Monday, January 07, 2002 2:10 AM
> >
> > ...
> >
> > The excuse of a good code base being to hard to
> understand so it should be
> > re-implemented doesn't fly with me.
> 
> A good code base should be easy to understand.
> 
> 
> > > This month, I am saddened by someone using his
> -1 to block progress
> > > towards contributing a reusable and independent
> code base to the
> commons.
> >
> > You forgot 'duplicated'.
> 
> If only one of them should stay, why Intake? Why is
> it better?
> 
> (Please no "this one is older" argument or I start
> thinking this is some
> kind of "public function" like community.)
> 
> David's Validator already has a clear advantage:
> someone already did turn
> it into an independent component... or maybe it was
> built that way.
> 
> 
> > > You want to know how management decisions are
> made?  We have a person
> > > volunteering to do the work based on the struts
> code base.
> > Unless there is
> > > a better offer out there, I see a rather easy
> management
> > decision to make.
> > > And that is coming from someone who tends
> towards non-intervention.
> >
> > However, good management knows what resources to
> allocate to what
> > responsibilities.
> >
> > This issue stems all the way back to the Tomcat3
> vs. Tomcat4 discussions.
> > Why is it a good thing to have half of the people
> working on T3
> > and half on T4?
> 
> Again? There was no half/half division. There was
> less people with T3.3
> and many of them would fork away of Jakarta if
> needed. They would not
> become T4 developers.
> 
> It was a "scratching the itch" problem. They wanted
> a production quality
> Tomcat ASAP and believed 3.3 was the one.
> 
> Now several of those developers are contributing to
> Tomcat 4 instead of
> to some SourceForge project.
> 
> This is Open Source, not a corporation. No
> management is going to impose
> where a given developer is going to spend his time,
> except _maybe_ if
> that developer is one of the few Open Source pros.
> 
> 
> > Why not combine the *limited* resources towards
> working on one common
> > codebase?
> 
> It happens as soon as everybody believes that a
> given codebase is
> clearly better than the other.
> 
> Maybe the only way to achieve the resource
> efficiency you pursue is to
> explain everybody which codebase is better and why
> 
> 
> Have fun,
> Paulo Gaspar
> 
> 
> --
> To unsubscribe, e-mail:  
> <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:commons-dev-help@jakarta.apache.org>
> 


__________________________________________________
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/

--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message