Re: [Springframework-developer] Keep Spring Focused

[Rod J. <rod...@in...>]

OK, I think we have 2 dangers:

1. Spring.jar gets to 2Mb, reference manual is 600 pages. Although the
design remains clean (IoC container doesn't depend on integrations etc)
users get confused and think Spring is complex and bloated. Even though t=
his
would arguably be a misconception, I don't want to spend my time arguing
about it.

2. Component hell. Jakarta Commons is terrifying. In this dystopic vision=
 of
the future, Spring ships as 27 Jar files. You need 7 to integrate with
Quartz, 6 (3 of them different) to integrate with Struts. Personally I us=
e
spring.jar in almost all cases, and hate having to manage numerous Jar
dependencies.

I favour a fairly simple solution to plot a safe course between, based on
the following approach.

- No componentization of what's been released in Spring 1.0 so far. E.g. =
I
wouldn't favour making FreeMarker or Velocity extensions. After all we do
offer different Jars already.
- One or at most 2 "Spring add-ons" projects, covering a range of
technologies, under the overall Spring Framework umbrella.
org.springframework.plugin or something as root package. Each with its ow=
n
manual, which assumes knowledge of Spring fundamentals.
- Minority interests should not be catered for in Spring. E.g. if someone
wants to integrate with some weird technology or other that "two clowns a=
nd
a dog" use (to steal a phrase) that shouldn't go into Spring proper.
Although we can link to it from a central page.

Another interesting point is where there might be multiple implementation=
s.
Take security. From what I've seen, Ben's security stuff is great and has=
 an
amazingly high level of documentation. So there's no question it meets
Spring's quality criteria, and that it's of interest to many Spring users.
But it's difficult to say that this should be "the security framework for
Spring" because security is such a tricky area. J2EE tried that and it
didn't work. So something like this being a sep product makes sense; a on=
e
size fits all solution is impossible.

I think Brandon made a suggestion that we should include something along =
the
lines of a commitment to "no bloat" in the mission statement. I think thi=
s
is a good idea, although of course we need to come up with suitable
phrasing. We _should_ guarantee to users that we won't be another EJB or
Commons.

Regards,
Rod


----- Original Message -----
From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Tuesday, April 06, 2004 11:40 PM
Subject: Re: [Springframework-developer] Keep Spring Focused


Brandon, all,

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 despit=
e
being in the same source directory. Our current strategy of providing bot=
h a
spring.jar and fine-grained individual jar files has received very positi=
ve
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 t=
o
become a collection of largely unrelated utilities, some of them with
hard-to-see cross-dependencies. The quality of concepts and implementatio=
ns
varies widely.

I guess that Spring cannot really be compared with Jakarta Commons in tha=
t
respect: Its vision is much more focused, even if covering a broad field =
and
numerous third-party integrations. Most importantly, Spring's implementat=
ion
is pretty consistent: We try very hard to apply similar patterns and reus=
e
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 shou=
ld
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 b=
ut
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 sma=
ll,
there is a point in *not* making it a separate project, IMO.

Juergen


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


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

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

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
integrated support for commons validator NOW people will grow to be used =
to
it as "the Spring" solution. Then when you introduce the "real" Spring
declarative validation you will have competing products within the framew=
ork
creating confusion. If commons validator is NOT going to be the "official=
"
Spring declarative validation then keep it OUT of the core distro. I do n=
ot
believe you are keeping focused in doing these type of things. You CAN
support things and help to keep them focused WITHOUT making it part of th=
e
core. Use a little collaboration for goodness sakes.

Brandon

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

Spring to me is about making it easier to build real applications quicker.
Since most applications (mine included) demand syntax and semantic
validation of business objects, I would argue a good declarative validati=
on
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 tha=
t's
the focus of the 1.1 declarative validation efforts.  However, we recogni=
ze
a substantial number of people out there already have an investment in
Struts/commons-validator--thus for us to provide a  _thin_ adapter for it
that facilitates integration with the rest of Spring helps those people.
And taking responsiblity for managing that piece helps ensure it stays
consistent with the rest of the framework in terms of quality (including
documentation and test coverage.)

So my point is when I see that the Spring team has taken responsibility f=
or
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, i=
s
tested), and that it will be managed and supported carefully over time.  =
Rod
and Juergen are not going to move something out of the sandbox into the c=
ore
and into a release without first making sure it's ready and there is a re=
al
need for it, for example.

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

I agree we don't need a million validator options, and we should say "no"=
 to
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 investmen=
t
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
use Spring but also needing it.  Long term, I'd like to see everyone usin=
g
our own declarative validation stuff that we're working on now, because w=
e
feel we can offer something better and with some unique capabilities.  Bu=
t
it's not ready yet (and even if it was people can't be expected to migrat=
e
everything on a dime, right?)

Keith

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

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

Any developers reading this?

Brandon

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

It's great that Spring offers a developer so many options, but after a wh=
ile
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 develop=
ers
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 ab=
out
the commons validator project.  With each new popular open source compone=
nt,
we will need yet another package checked into the Spring project.  We can
start now with the spring-commons-validator subproject.

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

I understand that. I'm simply saying... leave the choices on other websit=
es
and focus on what spring is. Not on all the neat toys you can plug into i=
t.
So, where do you draw the line on what does and does not get included. Wh=
y
not setup a directory of tools that can be used in spring instead of feel=
ing
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.

Brandon

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

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=3D1470&alloc_id=3D3638&op=3Dcli=
ck
_______________________________________________
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_id638&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer