[Springframework-developer] RE: commons-validator adapter

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Hello all,

To those that are worried about Spring breaking due to dependencies: have
you looked at the code for the Commons-Validator adaptor for Spring? Spring
certainly doesn't depend on any of those few small classes, and I would be
the first to say that the core of Spring should _never_ depend on them. I
contributed the code because I found Spring lacking a declarative validation
solution and I happened to have been using the Commons-Validator. Many
people out there also use the Commons-Validator; an adaptor for Spring is
one more reason to migrate from whatever other framework they are currently
tied into.

In my opinion, the major problem with the Commons-Validator as it was in
Struts was the difficulty involved in adding custom validation routines.
With Spring, this problem has disappeared. A Commons-Validator-backed
beanValidator can easily be wired into any custom validation class. With
this strategy, you can even conditionally execute the Commons-Validation
based on the outcome of other validations.

Having said all of that, I will say that I would give my personal blessing
to moving the adaptor I wrote into a separate "spring-plugins" jar that
would be distributed with Spring--like the other jars distributed with
Spring except that the code wouldn't be included in Spring.jar--or available
as a separate download linked from the Spring site. A close connection to
and easy availability of the plugins with the main Spring project is very
important. Part of the reason I chose Spring in the first place was its
_built-in_ support for so many different technologies. I really like being
able to drop a single Spring.jar into my lib dir and have all of the support
code needed to interface with other projects right there waiting to be used.
It saves me a lot of precious development time searching and researching
where to download the most recent, yet most compatible version of each
plugin.

Daniel Miller

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Tim Chen
Sent: Tuesday, April 06, 2004 5:48 PM
To: spr...@li...
Subject: Re: [Springframework-developer] RE: commons-validator adapter

I know that I'm new to the Spring world but just to make another note on
this subject.
Anyone that is on the Struts dev list can tell you that the latest
release of Commons Validator has been a huge sticking point in the
release of a new Struts version. I don't want to see the same thing
happen to Spring as to XDoclet neither as though on THAT list can tell
you. XDoclet has 10million dependencies (ok.. I exaggerate.. 999,999
dependencies) and most of them are broken which results in a XDoclet2
that does not build out of CVS. VERY VERY aggrevating.
Can I make a suggestion and vote to take a page from Maven's book?
Let's create a Spring-Plugin project of these "add-ons" they never have
to get mixed with the main code and the main code will NEVER have to
break due to breakages in the plugin's dependencies.
Even with this course the developers should still be careful what goes
into the core of course. XDoclet 2 came up with that same architecture
but unfortunately it's own core was tied too closely with other
*currently* broken packages.
-Tim

Rod Johnson wrote:

>Guys
>
>We are aware of the dangers here. We do not want Spring to become bloated,
>and it won't.
>
>So far we have the following strategies:
>
>- ** Keep the core separate from the add-ons ** E.g. the IoC container
>doesn't
>even depend on AOP, let alone Commons Validator/whatever. This means that
>it's possibly to use say the BeanFactory or JDBC without extensive
>dependencies: indeed, the whole of Spring (except integration) without
>extensive dependencies.
>- Keep the focus of the core developers on the core.
>- Set the bar high in terms of the quality of what we accept. This is one
>argument for keeping commonly-used add-ins in the Spring project.
>Let's suppose we don't address integration with a popular product such as
>Quartz. Several Spring/Quartz libraries then emerge, all but one of them
>bad. Now users are confused and it reflects poorly on Spring.
>- Ensure that the correct message gets out. Marketing is important. We must
>ensure that people know that the core doesn't depend on the extensions.
>
>However, I think this thread does show that we need to be careful in
>accepting too many add-ons into the core. Perhaps we could have an add-ons
>project for the second tier of integration: e.g. Hibernate is obviously
>core, Commons Validator could be shipped along with a Spring addons
>distribution, but which is still under the Spring Framework umbrella. Such
>integrations likely to be used commonly are definitely in a separate
>category from integration with highly specialized products, that are
>unlikely to see wide use. And we can always promote code into Spring
proper.
>
>Perhaps all integrations could start off in the add-ons project, and only
be
>promoted if there's user demand.
>
>Regarding documentation, good point, we should separate out the core from
>the add ons. Maybe 2 volumes of the reference manual. Also perhaps we
should
>provide a section on the web site helping users to understand what they
need
>to understand. This could be geared to real user situations, like "web
>development with Hibernate", "looking for a replacement for SLSBs",
"looking
>for quicker/easier JDBC".
>
>Regards,
>Rod
>
>----- Original Message -----
>From: "Baum, Karl" <Kar...@Ta...>
>To: <spr...@li...>
>Sent: Tuesday, April 06, 2004 4:33 AM
>Subject: Re: [Springframework-developer] RE: commons-validator adapter
>
>
>
>
>>It's great that Spring offers a developer so many options, but after a
>>
>>
>while
>
>
>>it may be difficult to separate core Spring from the convenient add ons.
>>What must a developer read up on before he or she understands what spring
>>
>>
>is
>
>
>>really about?  I would tend to side towards IOC, AOP, and the BeanFactory
>>before the commons validator plugin, but this does not mean a commons
>>validator plugin is not a great idea (I for one am trying to integrate it
>>into my current project.).  Each plugin that is integrated directly into
>>
>>
>the
>
>
>>project is yet another responsibility for the community of Spring
>>
>>
>developers
>
>
>>when it comes to documentation and maintenance.  This documentation, with
>>all of the add ons and plugins, will eventually become so bloated, the
>>average developer may become overwhelmed by it's size and complexity.
>>
>>Why not farm these plugins out to smaller subprojects with teams of
>>developers focused on delivering a specific add on to the Spring project.
>>This leaves everyone with all of the great Spring options, but in the end
>>the Spring Framework never loses site of it's purpose  This isn't just
>>
>>
>about
>
>
>>the commons validator project.  With each new popular open source
>>
>>
>component,
>
>
>>we will need yet another package checked into the Spring project.  We can
>>start now with the spring-commons-validator subproject.
>>
>>----- Original Message -----
>>From: "Brandon Goodin" <ma...@ph...>
>>To: <spr...@li...>
>>Sent: Monday, April 05, 2004 10:08 PM
>>Subject: RE: [Springframework-developer] RE: commons-validator adapter
>>
>>
>>
>>
>>>I understand that. I'm simply saying... leave the choices on other
>>>
>>>
>>websites
>>
>>
>>>and focus on what spring is. Not on all the neat toys you can plug into
>>>
>>>
>>it.
>>
>>
>>>So, where do you draw the line on what does and does not get included.
>>>
>>>
>Why
>
>
>>>not setup a directory of tools that can be used in spring instead of
>>>
>>>
>>feeling
>>
>>
>>>compelled to include support for every permutation into the distro or in
>>>
>>>
>>the
>>
>>
>>>spring cvs. Just cuz you can doesn't mean you should. I think moves like
>>>this will cause confusion around spring not help it.
>>>
>>>B
>>>
>>>-----Original Message-----
>>>From: spr...@li...
>>>[mailto:spr...@li...] On Behalf
>>>
>>>
>>Of
>>
>>
>>>Seth Ladd
>>>Sent: Monday, April 05, 2004 5:29 PM
>>>To: spr...@li...
>>>Subject: Re: [Springframework-developer] RE: commons-validator adapter
>>>
>>>Brandon Goodin wrote:
>>>
>>>
>>>>commons validator? gack! Don't pollute spring with all of this crap. I
>>>>don't want to see spring turn into the 8000 pound gorilla that struts
>>>>has. Please consider making this stuff peripheral.
>>>>
>>>>
>>>A nice aspect of Spring is that it attempts to give developers different
>>>choices for a particular task.  For validation, commons-validator is
>>>just one choice.  Other choices include metadata validator or
>>>programmatic validation.  IMHO, the commons-validator fills a nice
>>>niche: when you want to do declarative validation but can't mark up the
>>>source code (if, for example, you're using generated source or 3rd party
>>>classes).
>>>
>>>With Spring, you get to Pick and Choose!
>>>Seth
>>>
>>>
>>>-------------------------------------------------------
>>>This SF.Net email is sponsored by: IBM Linux Tutorials
>>>Free Linux tutorial presented by Daniel Robbins, President and CEO of
>>>GenToo technologies. Learn everything from fundamentals to system
>>>administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
>>>_______________________________________________
>>>Springframework-developer mailing list
>>>Spr...@li...
>>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>>
>>>
>>>
>>>
>>>
>>>-------------------------------------------------------
>>>This SF.Net email is sponsored by: IBM Linux Tutorials
>>>Free Linux tutorial presented by Daniel Robbins, President and CEO of
>>>GenToo technologies. Learn everything from fundamentals to system
>>>administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
>>>_______________________________________________
>>>Springframework-developer mailing list
>>>Spr...@li...
>>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>>
>>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by: IBM Linux Tutorials
>>Free Linux tutorial presented by Daniel Robbins, President and CEO of
>>GenToo technologies. Learn everything from fundamentals to system
>>administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
>>_______________________________________________
>>Springframework-developer mailing list
>>Spr...@li...
>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>
>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: IBM Linux Tutorials
>Free Linux tutorial presented by Daniel Robbins, President and CEO of
>GenToo technologies. Learn everything from fundamentals to system
>administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>

-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer