Re: [Springframework-developer] RE: commons-validator adapter

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

Thanks for the post Rod. Perhaps this should be part of the Spring
manifesto and stated on the site. :D

Also...
"Hibernate is obviously core," - wouldn't this be better worded as
"part of the core distribution"? Cuz it isn't part of the
spring-core.jar ;-) You are communicating the wrong message from the
previous statement of "- ** Keep the core separate from the add-ons **
E.g. the IoC container doesn't even depend on AOP, let alone Commons
Validator/whatever." How can us lemmings expect to follow such confusing
statements?

Hoping you guys have a sense of humor ;)
Brandon Goodin

>>> rod...@in... 4/6/2004 11:56:19 AM >>>

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