commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sam Ruby" <ru...@us.ibm.com>
Subject Re: Commons Validator Packaging/Content
Date Sun, 06 Jan 2002 23:25:42 GMT
Jon Scott Stevens 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?

Do it in the other way around (make it framework independent, then move it
into commons) and I think you may have a winner.  Meanwhile, it is probably
fair to assume that OTHERS will assume burying gems deep into the fabric of
your component is done for a reason.  In particular, the assumption will
likely be that the code is so intricately interwoven into the fabric of
your component that it would be difficult to break out.  I know that there
are examples of pre-gump days when attempts were made to break things out
that weren't successful; but then again, that was before there was a tool
that helped people monitor the stability of the interfaces.

> 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.

It is also easier to add a code directly to a subproject then to invest the
extra effort in making the code a standalone, reusable component.

<snip>

> 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.

Oh, there are definately a few things that need fixing around here.  Spend
a few minutes looking at
http://jakarta.apache.org/builds/gump/latest/xref.html .  Tell me what
patterns you see.  I see definate cleaving lines, and they are not along
any of the functional or scoping boundaries that we have been discussing
lately.  The good news is that these lines are getting harder to see every
day.  My current favorite example of a recent closing of one of the
fissures: jakarta-velocity-tools/struts.  Another favorite of mine is
jakarta-commons/collections, followed by jakarta-commons/beanutils.

- Sam Ruby


--
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