Re: [Springframework-developer] Keep Spring Focused

[<jue...@we...>]

Brandon, all,=20

That's a tough issue: It is far from trivial to decide whether to keep =
third-party integrations within the core framework. We currently focus =
on a quite extensive main project whose packages are strictly decoupled =
despite being in the same source directory. Our current strategy of =
providing both a spring.jar and fine-grained individual jar files has =
received very positive feedback.

A completely different strategy can be seen at Jakarta: Everything's a =
separate project there. Have a look at Commons: 28 individual components =
with separate distributions, plus 20 more in the sandbox. Commons seems =
to become a collection of largely unrelated utilities, some of them with =
hard-to-see cross-dependencies. The quality of concepts and =
implementations varies widely.

I guess that Spring cannot really be compared with Jakarta Commons in =
that respect: Its vision is much more focused, even if covering a broad =
field and numerous third-party integrations. Most importantly, Spring's =
implementation is pretty consistent: We try very hard to apply similar =
patterns and reuse other parts of the framework wherever we can. This is =
much easier within the same project, when the affected class versions =
definitely match.

I guess hardly anyone will argue that *all* third-party integrations =
should be moved outside the Spring core. JTA, JDO, Hibernate, iBATIS SQL =
Maps, JavaMail, JSTL, Velocity, Commons FileUpload, etc are all =
well-placed in the main project, I assume. Tiles and FreeMarker =
integrations are debatable but IMO still candidates for the main =
project: Where to draw the line? Why include Velocity integration in the =
main project but not FreeMarker?

This is also related to the current Struts Spring integration =
discussion. Where do such integration classes naturally fit: in Struts? =
in Spring? in a separate project, like the Struts Spring Plugin? Each =
separate project increases the number of jars to combine for typical =
applications, with matching dependencies... Particularly if the =
integration code is very small, there is a point in *not* making it a =
separate project, IMO.

Juergen=20


-----Original Message-----=20
From: spr...@li...=20
[mailto:spr...@li...]On Behalf=20
Of Brandon Goodin=20
Sent: Tuesday, April 06, 2004 5:18 PM=20
To: spr...@li...=20
Subject: [Springframework-developer] Keep Spring Focused WAS:=20
commons-validator adapter=20


Here is a summary of the previous threads that lead up to this =
discussion.=20
Please read an comment.=20

--- Brandon Goodin Mon 4/6/2004 ---=20

Do what you like. But, these are the same kind of near sighted arguments =

I've heard from the Struts group over the last 2 years. If you provide=20
integrated support for commons validator NOW people will grow to be used =
to=20
it as "the Spring" solution. Then when you introduce the "real" Spring=20
declarative validation you will have competing products within the =
framework=20
creating confusion. If commons validator is NOT going to be the =
"official"=20
Spring declarative validation then keep it OUT of the core distro. I do =
not=20
believe you are keeping focused in doing these type of things. You CAN=20
support things and help to keep them focused WITHOUT making it part of =
the=20
core. Use a little collaboration for goodness sakes.=20

Brandon=20

--- Keith Donald Mon 4/6/2004 ---=20

Spring to me is about making it easier to build real applications =
quicker.=20
Since most applications (mine included) demand syntax and semantic=20
validation of business objects, I would argue a good declarative =
validation=20
framework managed by the Spring team is a good fit.  Personally, I don't =

think commons-validator is that answer for us long term.  I think we can =

offer better and do so in a "cleaner" (more true Spring) fashion, and =
that's=20
the focus of the 1.1 declarative validation efforts.  However, we =
recognize=20
a substantial number of people out there already have an investment in=20
Struts/commons-validator--thus for us to provide a  _thin_ adapter for =
it=20
that facilitates integration with the rest of Spring helps those people. =

And taking responsiblity for managing that piece helps ensure it stays=20
consistent with the rest of the framework in terms of quality (including =

documentation and test coverage.)=20

So my point is when I see that the Spring team has taken responsibility =
for=20
an area and put their name on it, that says something about its quality: =

that is, that it is useful for one (it addresses a need, is documented, =
is=20
tested), and that it will be managed and supported carefully over time.  =
Rod=20
and Juergen are not going to move something out of the sandbox into the =
core=20
and into a release without first making sure it's ready and there is a =
real=20
need for it, for example.=20

We wouldn't want the emergence of a ton of decentralized Spring sub =
projects=20
to produce a sourceforge-like effect over time--that is, a lot of =
projects=20
that are inconsistent in terms of support-level/documentation/activity, =
etc=20
(and personally I prefer Spring as my one-stop-shop, reducing the =
headache=20
generally associated with managing technology integration [even then =
though,=20
it's still modular...]).   Please note this is not to say subprojects =
that=20
leverage Spring are a bad idea!  Heck no, just look at the new Acegi=20
Security Framework, for example!  There just needs to be a separation=20
between _what is_ Spring and what is a _separately managed_ project that =

builds on Spring.=20

I agree we don't need a million validator options, and we should say =
"no" to=20
things that aren't a good fit or don't address a clear, substantial user =

need.  So again the goal here is to allow those already with an =
investment=20
in commons-validator or Struts a way to easily integrate it with Spring. =

The adapter is to be quite thin and optional and there for people =
wanting to=20
use Spring but also needing it.  Long term, I'd like to see everyone =
using=20
our own declarative validation stuff that we're working on now, because =
we=20
feel we can offer something better and with some unique capabilities.  =
But=20
it's not ready yet (and even if it was people can't be expected to =
migrate=20
everything on a dime, right?)=20

Keith=20

--- Brandon Goodin Mon 4/5/2004 ---=20

This is exactly what I mean. Thanks Karl. I hope developers of Spring =
take=20
what Karl is saying to heart. To me this is vitally important in keeping =
the=20
reality and perception of Spring light and focused. I would hate to see=20
Spring suffer from what Struts suffers from... "fascination with =
gadgetry"=20
or BSOS (Bright Shiny Object Syndrome)...distraction from what is =
important.=20

Any developers reading this?=20

Brandon=20

--- Karl Baum Mon 4/5/2004 ---=20

It's great that Spring offers a developer so many options, but after a =
while=20
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=20
really about?  I would tend to side towards IOC, AOP, and the =
BeanFactory=20
before the commons validator plugin, but this does not mean a commons=20
validator plugin is not a great idea (I for one am trying to integrate =
it=20
into my current project.).  Each plugin that is integrated directly into =
the=20
project is yet another responsibility for the community of Spring =
developers=20
when it comes to documentation and maintenance.  This documentation, =
with=20
all of the add ons and plugins, will eventually become so bloated, the=20
average developer may become overwhelmed by it's size and complexity.=20

Why not farm these plugins out to smaller subprojects with teams of=20
developers focused on delivering a specific add on to the Spring =
project.=20
This leaves everyone with all of the great Spring options, but in the =
end=20
the Spring Framework never loses site of it's purpose  This isn't just =
about=20
the commons validator project.  With each new popular open source =
component,=20
we will need yet another package checked into the Spring project.  We =
can=20
start now with the spring-commons-validator subproject.=20

--- Brandon Goodin Mon 4/5/2004 ---=20

I understand that. I'm simply saying... leave the choices on other =
websites=20
and focus on what spring is. Not on all the neat toys you can plug into =
it.=20
So, where do you draw the line on what does and does not get included. =
Why=20
not setup a directory of tools that can be used in spring instead of =
feeling=20
compelled to include support for every permutation into the distro or in =
the=20
spring cvs. Just cuz you can doesn't mean you should. I think moves like =

this will cause confusion around spring not help it.=20

Brandon=20

--- Seth Ladd Mon 4/5/2004 ---=20

A nice aspect of Spring is that it attempts to give developers different =

choices for a particular task.  For validation, commons-validator is =
just=20
one choice.  Other choices include metadata validator or programmatic=20
validation.  IMHO, the commons-validator fills a nice=20
niche: when you want to do declarative validation but can't mark up the=20
source code (if, for example, you're using generated source or 3rd party =

classes).=20

With Spring, you get to Pick and Choose!=20
Seth.=20




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