springframework-developer — Spring Framework developers list

RE: [Springframework-developer] Keep Spring Focused

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

>I'd respectfully suggest the community develops some sort of
review/endorsement program so that reasonably related 
components - including
but not limited to security - can receive some form 
of "official" review. I
respect this takes up the time of community members, but the 
time invested
is far less than writing something from scratch. If a 
component is "up to
Spring standard" - with unit test coverage reports, reference 
documentation,
and JavaDocs - evaluation shouldn't demand copious amounts of 
time either.
Review does not represent a guarantee, but simply an 
indication of
reasonable treatment of a particular problem domain.

Great idea. Spring is also partly a brand, rather than just a 
framework.

RE: [Springframework-developer] Keep Spring Focused

[Ben A. <ben...@ac...>]

Hi all

> Another interesting point is where there might be multiple 
> implementations.
> 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 one size fits all solution 
> is impossible.

It seems the consensus is to keep the core lean and I agree. 

The related issue is Spring's "marketability" if it lacks an approach to
certain core capabilities. To illustrate, I've found there are four groups
of user expectations towards Spring security:

1. Those who expect Spring core to provide security
2. Those who would like Spring core developers to review/endorse some
external security component(s)
3. Those who just want a maintained, external, compatible security component
(Acegi Security System today)
4. Those who don't need Spring security (maybe they're writing their own or
just don't require security)

The present Spring "component ecosystem" doesn't support the many users in
groups one and two. Those in group three aren't particularly well catered
for either, as there is no central resource where existing AND POTENTIAL
users of Spring can discover related projects. Whilst there are the mailing
lists, many evaluators won't spend the time wading through them - particular
if another framework seems to obviously offer the desired capabilities. This
is disappointing for Spring, as it misses out on potential users who would
have fit into group three (ie not requiring any "official" component, just a
viable one).

I'd respectfully suggest the community develops some sort of
review/endorsement program so that reasonably related components - including
but not limited to security - can receive some form of "official" review. I
respect this takes up the time of community members, but the time invested
is far less than writing something from scratch. If a component is "up to
Spring standard" - with unit test coverage reports, reference documentation,
and JavaDocs - evaluation shouldn't demand copious amounts of time either.
Review does not represent a guarantee, but simply an indication of
reasonable treatment of a particular problem domain.

If evaluation is too much, can we at least have a list of links on the
Spring web site with a disclaimer indicating they have not been reviewed? At
least this would help new users and those evaluating Spring. 

Best regards
Ben

[Springframework-developer] Re: commons-validator adapter

[Keith D. <kd...@cs...>]

MessageDaniel,

The new declarative validation stuff will support both rule definition =
via source markup via attributes like you said, as well as a xml-based =
configuration via Spring IoC.  And there will still be the programmatic =
option for configuration (I'm a big believer in having a polished API =
that works just as well as the config files for those who still prefer =
that route.)

I think it's going to be quite powerful, more so than commons-validator, =
and easier to define new rules.  Right now you can define just about any =
validation expression you can think up using the rules API - and complex =
expressions (including compound expressions using And/Or/Not logical =
operators and all the standard binary operators) are possible.  For =
example, it's possible to define a rule that says: property "foo" is =
required if properties "bar" and "apple" are present, but not if =
"orange" is present.  If those rules change, the API is flexible enough =
tweak them without having to define a new class all together (the API =
provides very much a "building block" approach for composing rules.).  =
Similiary, you can say that property "foo" must be in the range of =
properties "lowBar" and "highBar" (or you can parameterize the property =
expressions and say that "foo" must be in the constant range of "1" to =
"255" for example...)

The predicate (rules) API is currently in the sandbox under =
src/sandbox/org/springframework/functor (functor might not be the best =
name for it - I just used it because the design is based on a functional =
style of programming (heavy on the strategy & chain of responsibility =
patterns) illustrated by commons-functor and Object space's JGL...) I =
think it is looking pretty good.  The next challenge -- what I am =
working on now -- is to integrate that API with a easy way of =
declaratively specifying rules in an external file/source attributes =
(basically nailing down that format, with emphasis on keeping the amount =
of config needed concise), and then hooking rule definition up to the =
validation results reporting classes for generating internationalized =
error messages and typing hints when bean validation occurs at runtime.  =
More advanced features include the ability to fire validation rules =
automatically when "constrained" set() methods are called on a javabean, =
either using AOP or the built in java-beans VetoChangeListener support.  =
The biggest challenge I've found there is figuring out, based on what =
rules effect what properties, which rules should fire on which set call. =
 That's not as easy as it seems when a single rule effects multiple =
properties.

Keith

----- Original Message -----=20
  From: Daniel Miller=20
  To: Keith Donald=20
  Sent: Wednesday, April 07, 2004 8:35 PM
  Subject: RE: commons-validator adapter


  Keith,

  My viewpoint for now is that if Juergen and Rod approve the code then =
its probably worth having it. I won't even be upset if it gets moved to =
a "spring-plugins" jar as long as it's made available for people to use.

  I agree, we should probably refactor them to reuse and share as much =
code between the commons and attributes validators as possible.

  I haven't had time to look at your attributes-based validator at all, =
so forgive me if I seem a bit ignorant. From what I understand, this =
attributes-based validation requires to be placed in the source code of =
the classes that would be validated. Is that correct? If so, is there =
any way we could create an XML configuration option like the =
Commons-Validator has (i.e. not dependent on attributes at all)? It =
would be really cool if it supported the same XML file format that the =
Commons-Validator does. What do you think?

  I'll keep you posted with any bugs that I find.

  Daniel
    -----Original Message-----
    From: Keith Donald [mailto:kd...@cs...]
    Sent: Tuesday, April 06, 2004 12:24 PM
    To: 'Daniel Miller'
    Subject: RE: commons-validator adapter


    Daniel,

    No problem.

    BTW - I didn't realize those were *struts* classes, I assumed they =
were commons-validator.  In that case it's probably going to be best for =
us to just refactor those classes against our own declarative validation =
support (which will provide a flexible API for defining rules.)  If you =
want to see some of the API in development, check out =
sandbox/src/org/springframework/functor/PredicateFactory.

    I'll keep you posted.  In the meantime if you find any bugs send 'em =
my way.

    Thanks,
    Keith

[Springframework-developer] Re: Struts Spring Plugin

[Tom C. <cT...@wo...>]

> > SpringAction's looking up of the corresponding Spring bean and setting the
> > ActionServlet can be significantly optimized. Actually, I consider the
> > current implementation unsafe: It first sets the ActionServlet on the located
> > Action (a shared instance) and then resets it to null again (on each
> > execution!). This is not at all thread-safe.

Juergen is right when he questions the thread-safety of resetting the
ActionServlet back to null. We've been doing some performance testing on a
project build using Hibernate, Spring and Struts, and have found a neat little
race condition with the SpringAction.
 
 Symptom:
 
 During high load we saw NPE's in the system log coming from actions
 invoked by the SpringAction. After a code review, we found that these
 were due to a null ActionServlet being present in the action. This was
 rather funny since the SpringAction provides the ActionServlet instance
 to each action it invokes. BUT it also clears the action in a finally
 block --> that's the problem.
 
 The solutions we have considered:
 
 1. Don't configure actions as singletons in Spring. This is the obvious
 solution, but not really a nice one, seeing as Actions are (sort of) 
 singletons in Struts, so why should it be any different in Spring. 
 
 2. Stop clearing the ActionServlet in the finally block of SpringAction.
 This is preferred, but since clearing the action is actually s Struts
 lifecycle event (i.e. it tells the action to cleanup its resources), it
 may still be required. This is where we put a little Spring-specific
 code into each action that needs resource cleanup --> each such action
 should implement org.springframework.beans.factory.DisposableBean so
 that it can cleanup when Spring tells it, rather than when Struts (or
 the SpringAction) does. Its actually appropriate for this, since we are
 using Spring-configured Struts actions, so why not have Spring control
 their destruction as well.

Just my opinion, mind you.
Tom.

Re: [Springframework-developer] Sandbox JMS included in Spring roadmap?

[Mark P. <Mar...@Co...>]

Hi,

The code that is in the sandbox will change alot, so I would not start
using it now.  Within the week there should be some code that is more in
line with the 1.x release.  One big difference is to not distinquish
between topics and queues and a lot of helper classes when receiving
messages.


Cheers,
Mark


> I see code relating to JMS in the sandbox and I see various discussions
> about JMS being added to the core including a few competing
> implementations.
>
> http://article.gmane.org/gmane.comp.java.springframework.devel/3794/match=jms
>
>
>
> Can someone verify for me that it is the sandbox JMS code that is targeted
> to be added to the core with the 1.X release. If so i'll start using it
> now, it looks fully functional for my current needs at least.
>
>
> Thanks.
> Sean Kroah
>
>
>
>
> -------------------------------------------------------
> 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
>

[Springframework-developer] JMS Sandbox to Spring 1.1...nevermind

[<sk...@fe...>]

I'll assume this is true

http://article.gmane.org/gmane.comp.java.springframework.devel/3793/match=jms

Thanks
Sean Kroah

[Springframework-developer] Sandbox JMS included in Spring roadmap?

[<sk...@fe...>]

I see code relating to JMS in the sandbox and I see various discussions
about JMS being added to the core including a few competing
implementations.

http://article.gmane.org/gmane.comp.java.springframework.devel/3794/match=jms



Can someone verify for me that it is the sandbox JMS code that is targeted
to be added to the core with the 1.X release. If so i'll start using it
now, it looks fully functional for my current needs at least.


Thanks.
Sean Kroah

Re: [Springframework-developer] Spring IDE - Eclipse Plugin:Migration of SpringUI finished; Version 1.0.0 ready

[<bro...@ya...>]

:-) actually being an avid IDEA user, and have done
some plugins it was just what i was thinking of
starting.. Have to finish some urgent things but was
planning to start May 15th, so if anyone wants to feed
through some i would like to haves in the plugin, i
would be more than happy to oblige

regards

 --- "jurgen holler [werk3AT]"
<jue...@we...> wrote: > What makes you
think that I'm a NetBeans user? ;-)
> Seriously, I've been working with IDEA for about 3
> years now. I used NetBeans / Forte for Java before
> that, though. I just never got around to actually
> work with Eclipse yet.
> 
> werk3AT is entirely an IDEA shop, so what I'd like
> to see is an IDEA plugin for editing Spring XML bean
> definitions. I certainly won't focus on this myself
> (the core is too important), but I nevertheless
> guess that it won't take very long until such an
> IDEA plugin sees the light of day :-)
> 
> Juergen
> 
> 
> -----Original Message-----
> From:
>
spr...@li...
>
[mailto:spr...@li...]On
> Behalf Of Nadeem Bitar
> Sent: Wednesday, April 07, 2004 4:37 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Spring IDE
> - Eclipse Plugin:Migration of SpringUI finished;
> Version 1.0.0 ready
> 
> 
> Juergen, since you're a netbeans user, is there any
> chance of a netbeans
> plugin? 
> 
> regards,
> Nadeem
> 
> On ¿å, 2004-04-07 at 15:52 +0200, j¡©rgen h¡©ller
> [werk3AT] wrote:
> 
> > Torsten,
> > 
> > Ehm, (Eclipse newbie here), you want me to upload
> the updatesite zip as file release? Shouldn't it
> rather be some installation zip a la
> "spring-ide-eclipse.zip"? I guess I have to learn
> something about how Eclipse plugins are distributed
> :-) 
> > 
> > Regarding the version number, we use "1.0" rather
> than "1.0.0" with the Spring distribution itself, so
> it's probably advisable to use the same numbering
> scheme with the Eclipse plugin.
> > 
> > As we're about to release Spring 1.0.1 next week,
> I'd like to do the Eclipse plugin 1.0 release in the
> same SourceForge upload session, and annouce both in
> the same mail. So there's still time to educate me
> in terms of Eclipse plugin distributions ;-)
> > 
> > Juergen
> > 
> > 
> > -----Original Message-----
> > From:
>
spr...@li...
> >
>
[mailto:spr...@li...]On
> Behalf
> > Of Torsten Juergeleit
> > Sent: Monday, April 05, 2004 10:43 PM
> > To:
> spr...@li...
> > Subject: [Springframework-developer] Spring IDE -
> Eclipse Plugin:
> > Migration of SpringUI finished; Version 1.0.0
> ready
> > 
> > 
> > I finished migrating the SpringUI Eclipse plugin
> into
> > the Spring CVS (new module 'spring-ide/eclipse/').
> > 
> > Now I am looking for a place to host the Eclipse
> > plugin's update site (web site with a config XML
> file
> > and two folders holding the plugin data). The
> update
> > site is used by Eclipse's update manager to
> download
> > different versions of the plugin directly from
> with
> > the IDE. Also an HTML file and a few screen copies
> > (with some infos about the plugin and it's update
> > site) has to be hosted somewhere.
> > 
> > To give an example I have stored the stuff in
> Spring's
> > (unused) webspace on SF.NET. The installation
> infos
> > can be found on 
> >
>
http://springframework.sourceforge.net/spring-ide/eclipse/
> > and the update site is available from
> >
>
http://springframework.sourceforge.net/spring-ide/eclipse/updatesite/.
> > 
> > 
> > Does it make sense to host the plugin's update
> site
> > and the corresponding HTML page on
> > http://www.springframework.org/ or is SF.NET ok
> (the
> > download of the Spring framework itself is hosted
> on
> > SF.NET too)?
> > 
> > 
> > J¡©rgen, you can create a file release on SF.NET
> for
> > the plugin, if you like. The corresponding archive
> > with version 1.0.0 of the plugin's update site is
> > available from
> >
>
http://springframework.sourceforge.net/spring-ide/eclipse/updatesite/updatesite_1.0.0.zip.
> > 
> > Torsten 
> > 
> > 
> > 
> > __________________________________
> > Do you Yahoo!?
> > Yahoo! Small Business $15K Web Design Giveaway 
> > http://promotions.yahoo.com/design_giveaway/
> > 
> > 
> >
>
-------------------------------------------------------
> > 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_id70&alloc_id638&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_id70&alloc_id638&op=ick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
>
https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
N¬HS^µéšŠX¬²š'²ŠÞu¼ˆÂâžìSºÚ+‰©l·ž.)îÆÛ­¢¸š–šÞ±éíyÖò
©âzThm¸§°úÞ²'^žÖ§t!¡ñž:(µç!ž‰h‚'¬-櫝ëÞ¯+aŠx®‰ŸºwZ™éíj[-¢Ì¬µéšvh§ŠËkjبžm§ÿÚvÊ,vw(›ö‰õã½–Z‰÷ë(§%‰É¦¸§úڙì(®G^½éh¥êæj)bž
> b²Ô©®)à~¶¦{
>
+‘ׯzZ)z¹b²Û,¢êÜyú+éÞ¶m¦Ïÿ–+-²Ê.­ÇŸ¢¸ë–+-³ùb²Ø§~ì¦¸§úڙì(®G^½éh¥ê 

________________________________________________________________________
Yahoo! Messenger - Communicate instantly..."Ping" 
your friends today! Download Messenger Now 
http://uk.messenger.yahoo.com/download/index.html

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

Re: [Springframework-developer] Spring IDE - Eclipse Plugin:Migration of SpringUI finished; Version 1.0.0 ready

[Eduardo I. I. <zi...@su...>]

I only miss the code completion on property names...

James Cook wrote:
> Just curious; what would an XML definition editor do?
> 
> I mean, IDEA already uses the DTD to prompt for appropriate tags and
> attributes. What else would be helpful?
> 

Re: [Springframework-developer] sf connection problems?

[Colin S. <col...@ex...>]

This is almost certainly an uppercase vs. lowercase issue; something 
such as the fact that you are on a windows system, and on the (unix) 
server, there is already a file (maybe in the attic) with the same name 
except for the case...


Keith Donald wrote:

>My latest error required me to change the name of a class before it would
>let me add it.  For some reason the server would NOT let me commit a new
>resource with that name...
>
>I kept getting:
>	spring: cvs: hash.c:312: findnode: Assertion `key != ((void *)0)'
>failed.
>
>... returned from the server (at least Eclipse said it came from the
>server.)
>
>Arggh - Keith
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...] On Behalf Of
>tho...@tr...
>Sent: Wednesday, April 07, 2004 12:11 PM
>To: spr...@li...
>Subject: Re: [Springframework-developer] sf connection problems?
>
>
>
>I'm having the same kind of issues.  It's more tha a _bit_ annoying :-)
>
>Anybody thought about dev.java.net? 
>
>Thomas
>
>
>
>Quoting Keith Donald <kd...@cs...>:
>
>  
>
>>Has anyone besides me been having trouble connecting to the 
>>sourceforge repository?
>> 
>>It frequently takes me 2 or 3 attempts to commit changes successfully. 
>>Eclipse M8 often reports a "I/O error occured: connection reset" (or 
>>something like that).  Or I get the wonderfully descriptive message 
>>"An error has occured." :-)
>> 
>>It works eventually, don't get me wrong, my changes are sticking--it's 
>>just a bit annoying. Keith
>>
>>    
>>
>
>
>
>
>
>-------------------------------------------------------
>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_id70&alloc_id638&op=click
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>  
>

Re: [Springframework-developer] Spring IDE - Eclipse Plugin:Migration of SpringUI finished; Version 1.0.0 ready

[Nadeem B. <na...@ea...>]

I agree with you that the core is too important and that is where you
should focus your resources.=20

For some reason I thought you were a netbeans user and thought you were
planing a netbeans module. I might work on that myself after finishing
my current project which is behind schedule.

-Nadeem=20


On =BF=E5, 2004-04-07 at 18:09 +0200, jurgen holler [werk3AT] wrote:

> What makes you think that I'm a NetBeans user? ;-) Seriously, I've been w=
orking with IDEA for about 3 years now. I used NetBeans / Forte for Java be=
fore that, though. I just never got around to actually work with Eclipse ye=
t.
>=20
> werk3AT is entirely an IDEA shop, so what I'd like to see is an IDEA plug=
in for editing Spring XML bean definitions. I certainly won't focus on this=
 myself (the core is too important), but I nevertheless guess that it won't=
 take very long until such an IDEA plugin sees the light of day :-)
>=20
> Juergen
>=20



>=20
> -----Original Message-----
> From: spr...@li... [mailto:sprin=
gfr...@li...]On Behalf Of Nadeem Bitar
> Sent: Wednesday, April 07, 2004 4:37 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Spring IDE - Eclipse Plugin:Migr=
ation of SpringUI finished; Version 1.0.0 ready
>=20
>=20
> Juergen, since you're a netbeans user, is there any chance of a netbeans
> plugin?=20
>=20
> regards,
> Nadeem
>=20
> On =BF=E5, 2004-04-07 at 15:52 +0200, j=A1=A9rgen h=A1=A9ller [werk3AT] w=
rote:
>=20
> > Torsten,
> >=20
> > Ehm, (Eclipse newbie here), you want me to upload the updatesite zip as=
 file release? Shouldn't it rather be some installation zip a la "spring-id=
e-eclipse.zip"? I guess I have to learn something about how Eclipse plugins=
 are distributed :-)=20
> >=20
> > Regarding the version number, we use "1.0" rather than "1.0.0" with the=
 Spring distribution itself, so it's probably advisable to use the same num=
bering scheme with the Eclipse plugin.
> >=20
> > As we're about to release Spring 1.0.1 next week, I'd like to do the Ec=
lipse plugin 1.0 release in the same SourceForge upload session, and annouc=
e both in the same mail. So there's still time to educate me in terms of Ec=
lipse plugin distributions ;-)
> >=20
> > Juergen
> >=20
> >=20
> > -----Original Message-----
> > From: spr...@li...
> > [mailto:spr...@li...]On Behalf
> > Of Torsten Juergeleit
> > Sent: Monday, April 05, 2004 10:43 PM
> > To: spr...@li...
> > Subject: [Springframework-developer] Spring IDE - Eclipse Plugin:
> > Migration of SpringUI finished; Version 1.0.0 ready
> >=20
> >=20
> > I finished migrating the SpringUI Eclipse plugin into
> > the Spring CVS (new module 'spring-ide/eclipse/').
> >=20
> > Now I am looking for a place to host the Eclipse
> > plugin's update site (web site with a config XML file
> > and two folders holding the plugin data). The update
> > site is used by Eclipse's update manager to download
> > different versions of the plugin directly from with
> > the IDE. Also an HTML file and a few screen copies
> > (with some infos about the plugin and it's update
> > site) has to be hosted somewhere.
> >=20
> > To give an example I have stored the stuff in Spring's
> > (unused) webspace on SF.NET. The installation infos
> > can be found on=20
> > http://springframework.sourceforge.net/spring-ide/eclipse/
> > and the update site is available from
> > http://springframework.sourceforge.net/spring-ide/eclipse/updatesite/.
> >=20
> >=20
> > Does it make sense to host the plugin's update site
> > and the corresponding HTML page on
> > http://www.springframework.org/ or is SF.NET ok (the
> > download of the Spring framework itself is hosted on
> > SF.NET too)?
> >=20
> >=20
> > J=A1=A9rgen, you can create a file release on SF.NET for
> > the plugin, if you like. The corresponding archive
> > with version 1.0.0 of the plugin's update site is
> > available from
> > http://springframework.sourceforge.net/spring-ide/eclipse/updatesite/up=
datesite_1.0.0.zip.
> >=20
> > Torsten=20
> >=20
> >=20
> >=20
> > __________________________________
> > Do you Yahoo!?
> > Yahoo! Small Business $15K Web Design Giveaway=20
> > http://promotions.yahoo.com/design_giveaway/
> >=20
> >=20
> > -------------------------------------------------------
> > 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=3Dc=
lick
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >=20
> >=20
> > -------------------------------------------------------
> > 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=3Dclick
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-developer
> --=20
>=20
>=20
>=20
> -------------------------------------------------------
> 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
> �N=18HS^=B5=E9=9A=8AX=9A'=8Au=88=04=C2=E2=9ES=BA=DA+=89l=16=9E.)=EE=C6=
=DB=AD=9A=96=9A=DE=B1=E9=EDy=D6=F2zThm=B8=A7=B0=FA=DE=B2'^=9E=D6=A7t!=0E=A1=
=F1=9E=9D:(=B5=E7!=9E=89h=82'-=E6=AB=9D=EB=DE+a=8Ax=1F=89=9FwZ=99=E9=EDj[-=
=A2=CC=B5=E9=9Avh=8Akj=D8=A8=9E=1Bmv,vw(=9B=9D=895=E3=BD=1A=96Z=1C=897=7F(=
=07%=89=12=A6=B8=81=99(G^=BD=E9h=A5=EAj)b=9E	b=B2=D4)~=B6=A6{
> +=91=D7=AFzZ)zb=B2=DB,=A2=EAy+=81=E9=DE=1Bm=A6=CF=96+-=B2=CA.=9F=1E=9D=7F=
=96+-=B3=F9b=B2=D8~=8F=EC=A6=B8=A7=81=99(G^=BD=E9h
--=20

Re: [Springframework-developer] Preparing for 1.0.1

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

>How do we want to proceed for 1.0.2 and 1.1.  Should we just 
add new features
and release what is stable for 1.0.2 or do we want to limit 
1.0.2 to strictly
bug fixes and hold on to any enhancements until 1.1?

I think 1.0.2 (if we need it!) should be strictly bug fixes. 
No enhancements, except possibly a new method here or there 
if it's 100% backward compatible. 

RE: [Springframework-developer] sf connection problems?

[Keith D. <kd...@cs...>]

My latest error required me to change the name of a class before it =
would
let me add it.  For some reason the server would NOT let me commit a new
resource with that name...

I kept getting:
	spring: cvs: hash.c:312: findnode: Assertion `key !=3D ((void *)0)'
failed.

... returned from the server (at least Eclipse said it came from the
server.)

Arggh - Keith


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
tho...@tr...
Sent: Wednesday, April 07, 2004 12:11 PM
To: spr...@li...
Subject: Re: [Springframework-developer] sf connection problems?



I'm having the same kind of issues.  It's more tha a _bit_ annoying :-)

Anybody thought about dev.java.net?=20

Thomas



Quoting Keith Donald <kd...@cs...>:

> Has anyone besides me been having trouble connecting to the=20
> sourceforge repository?
> =20
> It frequently takes me 2 or 3 attempts to commit changes successfully. =

> Eclipse M8 often reports a "I/O error occured: connection reset" (or=20
> something like that).  Or I get the wonderfully descriptive message=20
> "An error has occured." :-)
> =20
> It works eventually, don't get me wrong, my changes are sticking--it's =

> just a bit annoying. Keith
>=20





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

RE: [Springframework-developer] Spring IDE - Eclipse Plugin:Migration of SpringUI finished; Version 1.0.0 ready

[James C. <jim...@do...>]

SnVzdCBjdXJpb3VzOyB3aGF0IHdvdWxkIGFuIFhNTCBkZWZpbml0aW9uIGVkaXRvciBkbz8NCg0K
SSBtZWFuLCBJREVBIGFscmVhZHkgdXNlcyB0aGUgRFREIHRvIHByb21wdCBmb3IgYXBwcm9wcmlh
dGUgdGFncyBhbmQNCmF0dHJpYnV0ZXMuIFdoYXQgZWxzZSB3b3VsZCBiZSBoZWxwZnVsPw0KDQo+
IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IHNwcmluZ2ZyYW1ld29yay1kZXZl
bG9wZXItYWRtaW5AbGlzdHMuc291cmNlZm9yZ2UubmV0DQo+IFttYWlsdG86c3ByaW5nZnJhbWV3
b3JrLWRldmVsb3Blci1hZG1pbkBsaXN0cy5zb3VyY2Vmb3JnZS5uZXRdIE9uIEJlaGFsZg0KPiBP
ZiBqdXJnZW4gaG9sbGVyIFt3ZXJrM0FUXQ0KPiBTZW50OiBXZWRuZXNkYXksIEFwcmlsIDA3LCAy
MDA0IDEyOjEwIFBNDQo+IFRvOiBzcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyQGxpc3RzLnNvdXJj
ZWZvcmdlLm5ldA0KPiBTdWJqZWN0OiBSZTogW1NwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJdIFNw
cmluZyBJREUgLSBFY2xpcHNlDQo+IFBsdWdpbjpNaWdyYXRpb24gb2YgU3ByaW5nVUkgZmluaXNo
ZWQ7IFZlcnNpb24gMS4wLjAgcmVhZHkNCj4NCj4gV2hhdCBtYWtlcyB5b3UgdGhpbmsgdGhhdCBJ
J20gYSBOZXRCZWFucyB1c2VyPyA7LSkgU2VyaW91c2x5LCBJJ3ZlIGJlZW4NCj4gd29ya2luZyB3
aXRoIElERUEgZm9yIGFib3V0IDMgeWVhcnMgbm93LiBJIHVzZWQgTmV0QmVhbnMgLyBGb3J0ZSBm
b3IgSmF2YQ0KPiBiZWZvcmUgdGhhdCwgdGhvdWdoLiBJIGp1c3QgbmV2ZXIgZ290IGFyb3VuZCB0
byBhY3R1YWxseSB3b3JrIHdpdGggRWNsaXBzZQ0KPiB5ZXQuDQo+DQo+IHdlcmszQVQgaXMgZW50
aXJlbHkgYW4gSURFQSBzaG9wLCBzbyB3aGF0IEknZCBsaWtlIHRvIHNlZSBpcyBhbiBJREVBDQo+
IHBsdWdpbiBmb3IgZWRpdGluZyBTcHJpbmcgWE1MIGJlYW4gZGVmaW5pdGlvbnMuIEkgY2VydGFp
bmx5IHdvbid0IGZvY3VzIG9uDQo+IHRoaXMgbXlzZWxmICh0aGUgY29yZSBpcyB0b28gaW1wb3J0
YW50KSwgYnV0IEkgbmV2ZXJ0aGVsZXNzIGd1ZXNzIHRoYXQgaXQNCj4gd29uJ3QgdGFrZSB2ZXJ5
IGxvbmcgdW50aWwgc3VjaCBhbiBJREVBIHBsdWdpbiBzZWVzIHRoZSBsaWdodCBvZiBkYXkgOi0p
DQo+DQo+IEp1ZXJnZW4NCj4NCj4NCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJv
bTogc3ByaW5nZnJhbWV3b3JrLWRldmVsb3Blci1hZG1pbkBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQN
Cj4gW21haWx0bzpzcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyLWFkbWluQGxpc3RzLnNvdXJjZWZv
cmdlLm5ldF1PbiBCZWhhbGYgT2YNCj4gTmFkZWVtIEJpdGFyDQo+IFNlbnQ6IFdlZG5lc2RheSwg
QXByaWwgMDcsIDIwMDQgNDozNyBQTQ0KPiBUbzogc3ByaW5nZnJhbWV3b3JrLWRldmVsb3BlckBs
aXN0cy5zb3VyY2Vmb3JnZS5uZXQNCj4gU3ViamVjdDogUmU6IFtTcHJpbmdmcmFtZXdvcmstZGV2
ZWxvcGVyXSBTcHJpbmcgSURFIC0gRWNsaXBzZQ0KPiBQbHVnaW46TWlncmF0aW9uIG9mIFNwcmlu
Z1VJIGZpbmlzaGVkOyBWZXJzaW9uIDEuMC4wIHJlYWR5DQo+DQo+DQo+IEp1ZXJnZW4sIHNpbmNl
IHlvdSdyZSBhIG5ldGJlYW5zIHVzZXIsIGlzIHRoZXJlIGFueSBjaGFuY2Ugb2YgYSBuZXRiZWFu
cw0KPiBwbHVnaW4/DQo+DQo+IHJlZ2FyZHMsDQo+IE5hZGVlbQ0KPg0KPiBPbiAbJEI/ZRsoQiwg
MjAwNC0wNC0wNyBhdCAxNTo1MiArMDIwMCwgahskQiEpGyhCcmdlbiBoGyRCISkbKEJsbGVyIFt3
ZXJrM0FUXSB3cm90ZToNCj4NCj4gPiBUb3JzdGVuLA0KPiA+DQo+ID4gRWhtLCAoRWNsaXBzZSBu
ZXdiaWUgaGVyZSksIHlvdSB3YW50IG1lIHRvIHVwbG9hZCB0aGUgdXBkYXRlc2l0ZSB6aXAgYXMN
Cj4gZmlsZSByZWxlYXNlPyBTaG91bGRuJ3QgaXQgcmF0aGVyIGJlIHNvbWUgaW5zdGFsbGF0aW9u
IHppcCBhIGxhICJzcHJpbmctDQo+IGlkZS1lY2xpcHNlLnppcCI/IEkgZ3Vlc3MgSSBoYXZlIHRv
IGxlYXJuIHNvbWV0aGluZyBhYm91dCBob3cgRWNsaXBzZQ0KPiBwbHVnaW5zIGFyZSBkaXN0cmli
dXRlZCA6LSkNCj4gPg0KPiA+IFJlZ2FyZGluZyB0aGUgdmVyc2lvbiBudW1iZXIsIHdlIHVzZSAi
MS4wIiByYXRoZXIgdGhhbiAiMS4wLjAiIHdpdGggdGhlDQo+IFNwcmluZyBkaXN0cmlidXRpb24g
aXRzZWxmLCBzbyBpdCdzIHByb2JhYmx5IGFkdmlzYWJsZSB0byB1c2UgdGhlIHNhbWUNCj4gbnVt
YmVyaW5nIHNjaGVtZSB3aXRoIHRoZSBFY2xpcHNlIHBsdWdpbi4NCj4gPg0KPiA+IEFzIHdlJ3Jl
IGFib3V0IHRvIHJlbGVhc2UgU3ByaW5nIDEuMC4xIG5leHQgd2VlaywgSSdkIGxpa2UgdG8gZG8g
dGhlDQo+IEVjbGlwc2UgcGx1Z2luIDEuMCByZWxlYXNlIGluIHRoZSBzYW1lIFNvdXJjZUZvcmdl
IHVwbG9hZCBzZXNzaW9uLCBhbmQNCj4gYW5ub3VjZSBib3RoIGluIHRoZSBzYW1lIG1haWwuIFNv
IHRoZXJlJ3Mgc3RpbGwgdGltZSB0byBlZHVjYXRlIG1lIGluDQo+IHRlcm1zIG9mIEVjbGlwc2Ug
cGx1Z2luIGRpc3RyaWJ1dGlvbnMgOy0pDQo+ID4NCj4gPiBKdWVyZ2VuDQo+ID4NCj4gPg0KPiA+
IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogc3ByaW5nZnJhbWV3b3JrLWRl
dmVsb3Blci1hZG1pbkBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQNCj4gPiBbbWFpbHRvOnNwcmluZ2Zy
YW1ld29yay1kZXZlbG9wZXItYWRtaW5AbGlzdHMuc291cmNlZm9yZ2UubmV0XU9uIEJlaGFsZg0K
PiA+IE9mIFRvcnN0ZW4gSnVlcmdlbGVpdA0KPiA+IFNlbnQ6IE1vbmRheSwgQXByaWwgMDUsIDIw
MDQgMTA6NDMgUE0NCj4gPiBUbzogc3ByaW5nZnJhbWV3b3JrLWRldmVsb3BlckBsaXN0cy5zb3Vy
Y2Vmb3JnZS5uZXQNCj4gPiBTdWJqZWN0OiBbU3ByaW5nZnJhbWV3b3JrLWRldmVsb3Blcl0gU3By
aW5nIElERSAtIEVjbGlwc2UgUGx1Z2luOg0KPiA+IE1pZ3JhdGlvbiBvZiBTcHJpbmdVSSBmaW5p
c2hlZDsgVmVyc2lvbiAxLjAuMCByZWFkeQ0KPiA+DQo+ID4NCj4gPiBJIGZpbmlzaGVkIG1pZ3Jh
dGluZyB0aGUgU3ByaW5nVUkgRWNsaXBzZSBwbHVnaW4gaW50bw0KPiA+IHRoZSBTcHJpbmcgQ1ZT
IChuZXcgbW9kdWxlICdzcHJpbmctaWRlL2VjbGlwc2UvJykuDQo+ID4NCj4gPiBOb3cgSSBhbSBs
b29raW5nIGZvciBhIHBsYWNlIHRvIGhvc3QgdGhlIEVjbGlwc2UNCj4gPiBwbHVnaW4ncyB1cGRh
dGUgc2l0ZSAod2ViIHNpdGUgd2l0aCBhIGNvbmZpZyBYTUwgZmlsZQ0KPiA+IGFuZCB0d28gZm9s
ZGVycyBob2xkaW5nIHRoZSBwbHVnaW4gZGF0YSkuIFRoZSB1cGRhdGUNCj4gPiBzaXRlIGlzIHVz
ZWQgYnkgRWNsaXBzZSdzIHVwZGF0ZSBtYW5hZ2VyIHRvIGRvd25sb2FkDQo+ID4gZGlmZmVyZW50
IHZlcnNpb25zIG9mIHRoZSBwbHVnaW4gZGlyZWN0bHkgZnJvbSB3aXRoDQo+ID4gdGhlIElERS4g
QWxzbyBhbiBIVE1MIGZpbGUgYW5kIGEgZmV3IHNjcmVlbiBjb3BpZXMNCj4gPiAod2l0aCBzb21l
IGluZm9zIGFib3V0IHRoZSBwbHVnaW4gYW5kIGl0J3MgdXBkYXRlDQo+ID4gc2l0ZSkgaGFzIHRv
IGJlIGhvc3RlZCBzb21ld2hlcmUuDQo+ID4NCj4gPiBUbyBnaXZlIGFuIGV4YW1wbGUgSSBoYXZl
IHN0b3JlZCB0aGUgc3R1ZmYgaW4gU3ByaW5nJ3MNCj4gPiAodW51c2VkKSB3ZWJzcGFjZSBvbiBT
Ri5ORVQuIFRoZSBpbnN0YWxsYXRpb24gaW5mb3MNCj4gPiBjYW4gYmUgZm91bmQgb24NCj4gPiBo
dHRwOi8vc3ByaW5nZnJhbWV3b3JrLnNvdXJjZWZvcmdlLm5ldC9zcHJpbmctaWRlL2VjbGlwc2Uv
DQo+ID4gYW5kIHRoZSB1cGRhdGUgc2l0ZSBpcyBhdmFpbGFibGUgZnJvbQ0KPiA+IGh0dHA6Ly9z
cHJpbmdmcmFtZXdvcmsuc291cmNlZm9yZ2UubmV0L3NwcmluZy1pZGUvZWNsaXBzZS91cGRhdGVz
aXRlLy4NCj4gPg0KPiA+DQo+ID4gRG9lcyBpdCBtYWtlIHNlbnNlIHRvIGhvc3QgdGhlIHBsdWdp
bidzIHVwZGF0ZSBzaXRlDQo+ID4gYW5kIHRoZSBjb3JyZXNwb25kaW5nIEhUTUwgcGFnZSBvbg0K
PiA+IGh0dHA6Ly93d3cuc3ByaW5nZnJhbWV3b3JrLm9yZy8gb3IgaXMgU0YuTkVUIG9rICh0aGUN
Cj4gPiBkb3dubG9hZCBvZiB0aGUgU3ByaW5nIGZyYW1ld29yayBpdHNlbGYgaXMgaG9zdGVkIG9u
DQo+ID4gU0YuTkVUIHRvbyk/DQo+ID4NCj4gPg0KPiA+IEobJEIhKRsoQnJnZW4sIHlvdSBjYW4g
Y3JlYXRlIGEgZmlsZSByZWxlYXNlIG9uIFNGLk5FVCBmb3INCj4gPiB0aGUgcGx1Z2luLCBpZiB5
b3UgbGlrZS4gVGhlIGNvcnJlc3BvbmRpbmcgYXJjaGl2ZQ0KPiA+IHdpdGggdmVyc2lvbiAxLjAu
MCBvZiB0aGUgcGx1Z2luJ3MgdXBkYXRlIHNpdGUgaXMNCj4gPiBhdmFpbGFibGUgZnJvbQ0KPiA+
IGh0dHA6Ly9zcHJpbmdmcmFtZXdvcmsuc291cmNlZm9yZ2UubmV0L3NwcmluZy0NCj4gaWRlL2Vj
bGlwc2UvdXBkYXRlc2l0ZS91cGRhdGVzaXRlXzEuMC4wLnppcC4NCj4gPg0KPiA+IFRvcnN0ZW4N
Cj4gPg0KPiA+DQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+
ID4gRG8geW91IFlhaG9vIT8NCj4gPiBZYWhvbyEgU21hbGwgQnVzaW5lc3MgJDE1SyBXZWIgRGVz
aWduIEdpdmVhd2F5DQo+ID4gaHR0cDovL3Byb21vdGlvbnMueWFob28uY29tL2Rlc2lnbl9naXZl
YXdheS8NCj4gPg0KPiA+DQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+IFRoaXMgU0YuTmV0IGVtYWlsIGlzIHNwb25zb3JlZCBi
eTogSUJNIExpbnV4IFR1dG9yaWFscw0KPiA+IEZyZWUgTGludXggdHV0b3JpYWwgcHJlc2VudGVk
IGJ5IERhbmllbCBSb2JiaW5zLCBQcmVzaWRlbnQgYW5kIENFTyBvZg0KPiA+IEdlblRvbyB0ZWNo
bm9sb2dpZXMuIExlYXJuIGV2ZXJ5dGhpbmcgZnJvbSBmdW5kYW1lbnRhbHMgdG8gc3lzdGVtDQo+
ID4gYWRtaW5pc3RyYXRpb24uaHR0cDovL2Fkcy5vc2RuLmNvbS8/YWRfaWQ9MTQ3MCZhbGxvY19p
ZD0zNjM4Jm9wPWNsaWNrDQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX18NCj4gPiBTcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyIG1haWxpbmcgbGlzdA0K
PiA+IFNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJAbGlzdHMuc291cmNlZm9yZ2UubmV0DQo+ID4g
aHR0cHM6Ly9saXN0cy5zb3VyY2Vmb3JnZS5uZXQvbGlzdHMvbGlzdGluZm8vc3ByaW5nZnJhbWV3
b3JrLWRldmVsb3Blcg0KPiA+DQo+ID4NCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gVGhpcyBTRi5OZXQgZW1haWwgaXMgc3Bv
bnNvcmVkIGJ5OiBJQk0gTGludXggVHV0b3JpYWxzDQo+ID4gRnJlZSBMaW51eCB0dXRvcmlhbCBw
cmVzZW50ZWQgYnkgRGFuaWVsIFJvYmJpbnMsIFByZXNpZGVudCBhbmQgQ0VPIG9mDQo+ID4gR2Vu
VG9vIHRlY2hub2xvZ2llcy4gTGVhcm4gZXZlcnl0aGluZyBmcm9tIGZ1bmRhbWVudGFscyB0byBz
eXN0ZW0NCj4gPiBhZG1pbmlzdHJhdGlvbi5odHRwOi8vYWRzLm9zZG4uY29tLz9hZF9pZBQ3MCZh
bGxvY19pZDYzOCZvcD1jbGljaw0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fDQo+ID4gU3ByaW5nZnJhbWV3b3JrLWRldmVsb3BlciBtYWlsaW5nIGxp
c3QNCj4gPiBTcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyQGxpc3RzLnNvdXJjZWZvcmdlLm5ldA0K
PiA+IGh0dHBzOi8vbGlzdHMuc291cmNlZm9yZ2UubmV0L2xpc3RzL2xpc3RpbmZvL3NwcmluZ2Zy
YW1ld29yay1kZXZlbG9wZXINCj4gLS0NCj4NCj4NCj4NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBUaGlzIFNGLk5ldCBlbWFpbCBp
cyBzcG9uc29yZWQgYnk6IElCTSBMaW51eCBUdXRvcmlhbHMNCj4gRnJlZSBMaW51eCB0dXRvcmlh
bCBwcmVzZW50ZWQgYnkgRGFuaWVsIFJvYmJpbnMsIFByZXNpZGVudCBhbmQgQ0VPIG9mDQo+IEdl
blRvbyB0ZWNobm9sb2dpZXMuIExlYXJuIGV2ZXJ5dGhpbmcgZnJvbSBmdW5kYW1lbnRhbHMgdG8g
c3lzdGVtDQo+IGFkbWluaXN0cmF0aW9uLmh0dHA6Ly9hZHMub3Nkbi5jb20vP2FkX2lkFDcwJmFs
bG9jX2lkNjM4Jm9wPWljaw0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXw0KPiBTcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyIG1haWxpbmcgbGlzdA0KPiBT
cHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyQGxpc3RzLnNvdXJjZWZvcmdlLm5ldA0KPiBodHRwczov
L2xpc3RzLnNvdXJjZWZvcmdlLm5ldC9saXN0cy9saXN0aW5mby9zcHJpbmdmcmFtZXdvcmstZGV2
ZWxvcGVyDQo+IE4YSFMbJEI1aTM5MXgxaBsoQnUbJEIhJkF8bDpZZyEmOFAbKEIpGyRCRlshJkt6
MWkbKEJ5GyRCISYhJhsoQlRtGyRCODB6MhsoQicbJEJbexsoQnIhGyRCIXEhJjVnW2khJhsoQi0b
JEJle2svGyhCKxskQjNZLWc5VlJnGyhCDQo+IFsbJEIiTDVpGyhCdmgbJEIzdhsoQg0KPiAbJEJX
fBsoQhsbJEIoIRsoQnYbJEJJVRsoQncbJEJWbSEmGyhCNg0KDQoNCg==

Re: [Springframework-developer] Spring IDE - Eclipse Plugin:Migration of SpringUI finished; Version 1.0.0 ready

[jurgen h. [werk3AT] <jue...@we...>]

V2hhdCBtYWtlcyB5b3UgdGhpbmsgdGhhdCBJJ20gYSBOZXRCZWFucyB1c2VyPyA7LSkgU2VyaW91
c2x5LCBJJ3ZlIGJlZW4gd29ya2luZyB3aXRoIElERUEgZm9yIGFib3V0IDMgeWVhcnMgbm93LiBJ
IHVzZWQgTmV0QmVhbnMgLyBGb3J0ZSBmb3IgSmF2YSBiZWZvcmUgdGhhdCwgdGhvdWdoLiBJIGp1
c3QgbmV2ZXIgZ290IGFyb3VuZCB0byBhY3R1YWxseSB3b3JrIHdpdGggRWNsaXBzZSB5ZXQuDQoN
CndlcmszQVQgaXMgZW50aXJlbHkgYW4gSURFQSBzaG9wLCBzbyB3aGF0IEknZCBsaWtlIHRvIHNl
ZSBpcyBhbiBJREVBIHBsdWdpbiBmb3IgZWRpdGluZyBTcHJpbmcgWE1MIGJlYW4gZGVmaW5pdGlv
bnMuIEkgY2VydGFpbmx5IHdvbid0IGZvY3VzIG9uIHRoaXMgbXlzZWxmICh0aGUgY29yZSBpcyB0
b28gaW1wb3J0YW50KSwgYnV0IEkgbmV2ZXJ0aGVsZXNzIGd1ZXNzIHRoYXQgaXQgd29uJ3QgdGFr
ZSB2ZXJ5IGxvbmcgdW50aWwgc3VjaCBhbiBJREVBIHBsdWdpbiBzZWVzIHRoZSBsaWdodCBvZiBk
YXkgOi0pDQoNCkp1ZXJnZW4NCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog
c3ByaW5nZnJhbWV3b3JrLWRldmVsb3Blci1hZG1pbkBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQgW21h
aWx0bzpzcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyLWFkbWluQGxpc3RzLnNvdXJjZWZvcmdlLm5l
dF1PbiBCZWhhbGYgT2YgTmFkZWVtIEJpdGFyDQpTZW50OiBXZWRuZXNkYXksIEFwcmlsIDA3LCAy
MDA0IDQ6MzcgUE0NClRvOiBzcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyQGxpc3RzLnNvdXJjZWZv
cmdlLm5ldA0KU3ViamVjdDogUmU6IFtTcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyXSBTcHJpbmcg
SURFIC0gRWNsaXBzZSBQbHVnaW46TWlncmF0aW9uIG9mIFNwcmluZ1VJIGZpbmlzaGVkOyBWZXJz
aW9uIDEuMC4wIHJlYWR5DQoNCg0KSnVlcmdlbiwgc2luY2UgeW91J3JlIGEgbmV0YmVhbnMgdXNl
ciwgaXMgdGhlcmUgYW55IGNoYW5jZSBvZiBhIG5ldGJlYW5zDQpwbHVnaW4/IA0KDQpyZWdhcmRz
LA0KTmFkZWVtDQoNCk9uIL/lLCAyMDA0LTA0LTA3IGF0IDE1OjUyICswMjAwLCBqoalyZ2VuIGih
qWxsZXIgW3dlcmszQVRdIHdyb3RlOg0KDQo+IFRvcnN0ZW4sDQo+IA0KPiBFaG0sIChFY2xpcHNl
IG5ld2JpZSBoZXJlKSwgeW91IHdhbnQgbWUgdG8gdXBsb2FkIHRoZSB1cGRhdGVzaXRlIHppcCBh
cyBmaWxlIHJlbGVhc2U/IFNob3VsZG4ndCBpdCByYXRoZXIgYmUgc29tZSBpbnN0YWxsYXRpb24g
emlwIGEgbGEgInNwcmluZy1pZGUtZWNsaXBzZS56aXAiPyBJIGd1ZXNzIEkgaGF2ZSB0byBsZWFy
biBzb21ldGhpbmcgYWJvdXQgaG93IEVjbGlwc2UgcGx1Z2lucyBhcmUgZGlzdHJpYnV0ZWQgOi0p
IA0KPiANCj4gUmVnYXJkaW5nIHRoZSB2ZXJzaW9uIG51bWJlciwgd2UgdXNlICIxLjAiIHJhdGhl
ciB0aGFuICIxLjAuMCIgd2l0aCB0aGUgU3ByaW5nIGRpc3RyaWJ1dGlvbiBpdHNlbGYsIHNvIGl0
J3MgcHJvYmFibHkgYWR2aXNhYmxlIHRvIHVzZSB0aGUgc2FtZSBudW1iZXJpbmcgc2NoZW1lIHdp
dGggdGhlIEVjbGlwc2UgcGx1Z2luLg0KPiANCj4gQXMgd2UncmUgYWJvdXQgdG8gcmVsZWFzZSBT
cHJpbmcgMS4wLjEgbmV4dCB3ZWVrLCBJJ2QgbGlrZSB0byBkbyB0aGUgRWNsaXBzZSBwbHVnaW4g
MS4wIHJlbGVhc2UgaW4gdGhlIHNhbWUgU291cmNlRm9yZ2UgdXBsb2FkIHNlc3Npb24sIGFuZCBh
bm5vdWNlIGJvdGggaW4gdGhlIHNhbWUgbWFpbC4gU28gdGhlcmUncyBzdGlsbCB0aW1lIHRvIGVk
dWNhdGUgbWUgaW4gdGVybXMgb2YgRWNsaXBzZSBwbHVnaW4gZGlzdHJpYnV0aW9ucyA7LSkNCj4g
DQo+IEp1ZXJnZW4NCj4gDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9t
OiBzcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyLWFkbWluQGxpc3RzLnNvdXJjZWZvcmdlLm5ldA0K
PiBbbWFpbHRvOnNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXItYWRtaW5AbGlzdHMuc291cmNlZm9y
Z2UubmV0XU9uIEJlaGFsZg0KPiBPZiBUb3JzdGVuIEp1ZXJnZWxlaXQNCj4gU2VudDogTW9uZGF5
LCBBcHJpbCAwNSwgMjAwNCAxMDo0MyBQTQ0KPiBUbzogc3ByaW5nZnJhbWV3b3JrLWRldmVsb3Bl
ckBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQNCj4gU3ViamVjdDogW1NwcmluZ2ZyYW1ld29yay1kZXZl
bG9wZXJdIFNwcmluZyBJREUgLSBFY2xpcHNlIFBsdWdpbjoNCj4gTWlncmF0aW9uIG9mIFNwcmlu
Z1VJIGZpbmlzaGVkOyBWZXJzaW9uIDEuMC4wIHJlYWR5DQo+IA0KPiANCj4gSSBmaW5pc2hlZCBt
aWdyYXRpbmcgdGhlIFNwcmluZ1VJIEVjbGlwc2UgcGx1Z2luIGludG8NCj4gdGhlIFNwcmluZyBD
VlMgKG5ldyBtb2R1bGUgJ3NwcmluZy1pZGUvZWNsaXBzZS8nKS4NCj4gDQo+IE5vdyBJIGFtIGxv
b2tpbmcgZm9yIGEgcGxhY2UgdG8gaG9zdCB0aGUgRWNsaXBzZQ0KPiBwbHVnaW4ncyB1cGRhdGUg
c2l0ZSAod2ViIHNpdGUgd2l0aCBhIGNvbmZpZyBYTUwgZmlsZQ0KPiBhbmQgdHdvIGZvbGRlcnMg
aG9sZGluZyB0aGUgcGx1Z2luIGRhdGEpLiBUaGUgdXBkYXRlDQo+IHNpdGUgaXMgdXNlZCBieSBF
Y2xpcHNlJ3MgdXBkYXRlIG1hbmFnZXIgdG8gZG93bmxvYWQNCj4gZGlmZmVyZW50IHZlcnNpb25z
IG9mIHRoZSBwbHVnaW4gZGlyZWN0bHkgZnJvbSB3aXRoDQo+IHRoZSBJREUuIEFsc28gYW4gSFRN
TCBmaWxlIGFuZCBhIGZldyBzY3JlZW4gY29waWVzDQo+ICh3aXRoIHNvbWUgaW5mb3MgYWJvdXQg
dGhlIHBsdWdpbiBhbmQgaXQncyB1cGRhdGUNCj4gc2l0ZSkgaGFzIHRvIGJlIGhvc3RlZCBzb21l
d2hlcmUuDQo+IA0KPiBUbyBnaXZlIGFuIGV4YW1wbGUgSSBoYXZlIHN0b3JlZCB0aGUgc3R1ZmYg
aW4gU3ByaW5nJ3MNCj4gKHVudXNlZCkgd2Vic3BhY2Ugb24gU0YuTkVULiBUaGUgaW5zdGFsbGF0
aW9uIGluZm9zDQo+IGNhbiBiZSBmb3VuZCBvbiANCj4gaHR0cDovL3NwcmluZ2ZyYW1ld29yay5z
b3VyY2Vmb3JnZS5uZXQvc3ByaW5nLWlkZS9lY2xpcHNlLw0KPiBhbmQgdGhlIHVwZGF0ZSBzaXRl
IGlzIGF2YWlsYWJsZSBmcm9tDQo+IGh0dHA6Ly9zcHJpbmdmcmFtZXdvcmsuc291cmNlZm9yZ2Uu
bmV0L3NwcmluZy1pZGUvZWNsaXBzZS91cGRhdGVzaXRlLy4NCj4gDQo+IA0KPiBEb2VzIGl0IG1h
a2Ugc2Vuc2UgdG8gaG9zdCB0aGUgcGx1Z2luJ3MgdXBkYXRlIHNpdGUNCj4gYW5kIHRoZSBjb3Jy
ZXNwb25kaW5nIEhUTUwgcGFnZSBvbg0KPiBodHRwOi8vd3d3LnNwcmluZ2ZyYW1ld29yay5vcmcv
IG9yIGlzIFNGLk5FVCBvayAodGhlDQo+IGRvd25sb2FkIG9mIHRoZSBTcHJpbmcgZnJhbWV3b3Jr
IGl0c2VsZiBpcyBob3N0ZWQgb24NCj4gU0YuTkVUIHRvbyk/DQo+IA0KPiANCj4gSqGpcmdlbiwg
eW91IGNhbiBjcmVhdGUgYSBmaWxlIHJlbGVhc2Ugb24gU0YuTkVUIGZvcg0KPiB0aGUgcGx1Z2lu
LCBpZiB5b3UgbGlrZS4gVGhlIGNvcnJlc3BvbmRpbmcgYXJjaGl2ZQ0KPiB3aXRoIHZlcnNpb24g
MS4wLjAgb2YgdGhlIHBsdWdpbidzIHVwZGF0ZSBzaXRlIGlzDQo+IGF2YWlsYWJsZSBmcm9tDQo+
IGh0dHA6Ly9zcHJpbmdmcmFtZXdvcmsuc291cmNlZm9yZ2UubmV0L3NwcmluZy1pZGUvZWNsaXBz
ZS91cGRhdGVzaXRlL3VwZGF0ZXNpdGVfMS4wLjAuemlwLg0KPiANCj4gVG9yc3RlbiANCj4gDQo+
IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBEbyB5b3UgWWFo
b28hPw0KPiBZYWhvbyEgU21hbGwgQnVzaW5lc3MgJDE1SyBXZWIgRGVzaWduIEdpdmVhd2F5IA0K
PiBodHRwOi8vcHJvbW90aW9ucy55YWhvby5jb20vZGVzaWduX2dpdmVhd2F5Lw0KPiANCj4gDQo+
IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N
Cj4gVGhpcyBTRi5OZXQgZW1haWwgaXMgc3BvbnNvcmVkIGJ5OiBJQk0gTGludXggVHV0b3JpYWxz
DQo+IEZyZWUgTGludXggdHV0b3JpYWwgcHJlc2VudGVkIGJ5IERhbmllbCBSb2JiaW5zLCBQcmVz
aWRlbnQgYW5kIENFTyBvZg0KPiBHZW5Ub28gdGVjaG5vbG9naWVzLiBMZWFybiBldmVyeXRoaW5n
IGZyb20gZnVuZGFtZW50YWxzIHRvIHN5c3RlbQ0KPiBhZG1pbmlzdHJhdGlvbi5odHRwOi8vYWRz
Lm9zZG4uY29tLz9hZF9pZD0xNDcwJmFsbG9jX2lkPTM2Mzgmb3A9Y2xpY2sNCj4gX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gU3ByaW5nZnJhbWV3b3Jr
LWRldmVsb3BlciBtYWlsaW5nIGxpc3QNCj4gU3ByaW5nZnJhbWV3b3JrLWRldmVsb3BlckBsaXN0
cy5zb3VyY2Vmb3JnZS5uZXQNCj4gaHR0cHM6Ly9saXN0cy5zb3VyY2Vmb3JnZS5uZXQvbGlzdHMv
bGlzdGluZm8vc3ByaW5nZnJhbWV3b3JrLWRldmVsb3Blcg0KPiANCj4gDQo+IC0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gVGhpcyBTRi5O
ZXQgZW1haWwgaXMgc3BvbnNvcmVkIGJ5OiBJQk0gTGludXggVHV0b3JpYWxzDQo+IEZyZWUgTGlu
dXggdHV0b3JpYWwgcHJlc2VudGVkIGJ5IERhbmllbCBSb2JiaW5zLCBQcmVzaWRlbnQgYW5kIENF
TyBvZg0KPiBHZW5Ub28gdGVjaG5vbG9naWVzLiBMZWFybiBldmVyeXRoaW5nIGZyb20gZnVuZGFt
ZW50YWxzIHRvIHN5c3RlbQ0KPiBhZG1pbmlzdHJhdGlvbi5odHRwOi8vYWRzLm9zZG4uY29tLz9h
ZF9pZBQ3MCZhbGxvY19pZDYzOCZvcD1jbGljaw0KPiBfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXw0KPiBTcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyIG1haWxp
bmcgbGlzdA0KPiBTcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyQGxpc3RzLnNvdXJjZWZvcmdlLm5l
dA0KPiBodHRwczovL2xpc3RzLnNvdXJjZWZvcmdlLm5ldC9saXN0cy9saXN0aW5mby9zcHJpbmdm
cmFtZXdvcmstZGV2ZWxvcGVyDQotLSANCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClRoaXMgU0YuTmV0IGVtYWlsIGlzIHNwb25z
b3JlZCBieTogSUJNIExpbnV4IFR1dG9yaWFscw0KRnJlZSBMaW51eCB0dXRvcmlhbCBwcmVzZW50
ZWQgYnkgRGFuaWVsIFJvYmJpbnMsIFByZXNpZGVudCBhbmQgQ0VPIG9mDQpHZW5Ub28gdGVjaG5v
bG9naWVzLiBMZWFybiBldmVyeXRoaW5nIGZyb20gZnVuZGFtZW50YWxzIHRvIHN5c3RlbQ0KYWRt
aW5pc3RyYXRpb24uaHR0cDovL2Fkcy5vc2RuLmNvbS8/YWRfaWQUNzAmYWxsb2NfaWQ2Mzgmb3A9
aWNrDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KU3By
aW5nZnJhbWV3b3JrLWRldmVsb3BlciBtYWlsaW5nIGxpc3QNClNwcmluZ2ZyYW1ld29yay1kZXZl
bG9wZXJAbGlzdHMuc291cmNlZm9yZ2UubmV0DQpodHRwczovL2xpc3RzLnNvdXJjZWZvcmdlLm5l
dC9saXN0cy9saXN0aW5mby9zcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyDQo=

Re: [Springframework-developer] sf connection problems?

[<tho...@tr...>]

I'm having the same kind of issues.  It's more tha a _bit_ annoying :-)

Anybody thought about dev.java.net? 

Thomas



Quoting Keith Donald <kd...@cs...>:

> Has anyone besides me been having trouble connecting to the sourceforge
> repository?
>  
> It frequently takes me 2 or 3 attempts to commit changes successfully.
> Eclipse M8 often reports a "I/O error occured: connection reset" (or
> something like that).  Or I get the wonderfully descriptive message "An
> error has occured." :-)
>  
> It works eventually, don't get me wrong, my changes are sticking--it's just
> a bit annoying. Keith
> 

Re: [Springframework-developer] Spring IDE - Eclipse Plugin: Migration of SpringUI finished; Version 1.0.0 ready

[Torsten J. <tju...@ya...>]

Jürgen,

some infos regarding "Eclipse for Runaways" ;-)

> Ehm, (Eclipse newbie here), you want me to upload
> the updatesite zip as file release? Shouldn't it
> rather be some installation zip a la
> "spring-ide-eclipse.zip"?

The file
http://springframework.sourceforge.net/spring-ide/eclipse/updatesite/updatesite_1.0.0.zip
is not a "normal" archive with Eclipse plugins which
you can unzip in the Eclipse plugins folder. Instead
it's a copy of the whole update site
http://springframework.sourceforge.net/spring-ide/eclipse/updatesite/
which you can download (and use locally) if you are
sitting behind a restrictive proxy / firewall (like me
:-( ) which does not allow your Eclipse update manager
to install Eclipse plugins via an internet connection.

Distributing Eclipse plugins via the Eclipse update
manager mechanism is the way recommended by the
Eclipse team. The update site (which allows to install
the plugins via Eclipse update manager) should be IMHO
our preferred distribution channel. The additional
file release is only a goody for corporate admins
supporting a network installation of multiple Eclipse
users or Eclipse users behind a restricted proxy.

With the update site we have no information about the
download / usage count. But who cares about numbers
;-)


IMHO using the prefix "spring-ide-" for the file
release of the update site is redundant. This prefix
is the same as the package name of the corresponding
file release. So we will have (in addition to the
already existing file release package
"springframework") a new package named "spring-ide /
eclipse" or "spring-ide-eclipse".

For an example please refer to the old SpringUI file
releases
http://sourceforge.net/project/showfiles.php?group_id=99715


> Regarding the version number, we use "1.0" rather
> than "1.0.0" with the Spring distribution itself, so
> it's probably advisable to use the same numbering
> scheme with the Eclipse plugin.

Hhmm, the versioning schema for Eclipse plugins /
features / fragments is <major>.<minor>.<service>.

Quote from
http://www.eclipse.org/documentation/html/plugins/org.eclipse.platform.doc.isv/doc/reference/misc/eclipse_install.html
:

"...
The version identifier follows the format defined by
Eclipse for plug-in version identifiers (see javadoc
for PluginVersionIdentifier class). It is a 3-part
numeric identifier consisting of major, minor and
service components (eg. 2.4.11)
..."

No problem with an initial release 1.0 but how about
maintenance releases?


Btw. where should the Eclipse update site be hosted?
Is
http://springframework.sourceforge.net/spring-ide/eclipse/updatesite/
ok?

If we are hosting it on
http://www.springframework.org/ then we need a place
to upload new versions ready to be transfered to our
website. IMHO sending new versions via mail is no
viable option.

Torsten

--- jürgen_höller_[werk3AT]
<jue...@we...> wrote:
> Torsten,
> 
> Ehm, (Eclipse newbie here), you want me to upload
> the updatesite zip as file release? Shouldn't it
> rather be some installation zip a la
> "spring-ide-eclipse.zip"? I guess I have to learn
> something about how Eclipse plugins are distributed
> :-) 
> 
> Regarding the version number, we use "1.0" rather
> than "1.0.0" with the Spring distribution itself, so
> it's probably advisable to use the same numbering
> scheme with the Eclipse plugin.
> 
> As we're about to release Spring 1.0.1 next week,
> I'd like to do the Eclipse plugin 1.0 release in the
> same SourceForge upload session, and annouce both in
> the same mail. So there's still time to educate me
> in terms of Eclipse plugin distributions ;-)
> 
> Juergen
> 
> 
> -----Original Message-----
> From:
>
spr...@li...
>
[mailto:spr...@li...]On
> Behalf
> Of Torsten Juergeleit
> Sent: Monday, April 05, 2004 10:43 PM
> To: spr...@li...
> Subject: [Springframework-developer] Spring IDE -
> Eclipse Plugin:
> Migration of SpringUI finished; Version 1.0.0 ready
> 
> 
> I finished migrating the SpringUI Eclipse plugin
> into
> the Spring CVS (new module 'spring-ide/eclipse/').
> 
> Now I am looking for a place to host the Eclipse
> plugin's update site (web site with a config XML
> file
> and two folders holding the plugin data). The update
> site is used by Eclipse's update manager to download
> different versions of the plugin directly from with
> the IDE. Also an HTML file and a few screen copies
> (with some infos about the plugin and it's update
> site) has to be hosted somewhere.
> 
> To give an example I have stored the stuff in
> Spring's
> (unused) webspace on SF.NET. The installation infos
> can be found on 
>
http://springframework.sourceforge.net/spring-ide/eclipse/
> and the update site is available from
>
http://springframework.sourceforge.net/spring-ide/eclipse/updatesite/.
> 
> 
> Does it make sense to host the plugin's update site
> and the corresponding HTML page on
> http://www.springframework.org/ or is SF.NET ok (the
> download of the Spring framework itself is hosted on
> SF.NET too)?
> 
> 
> Jürgen, you can create a file release on SF.NET for
> the plugin, if you like. The corresponding archive
> with version 1.0.0 of the plugin's update site is
> available from
>
http://springframework.sourceforge.net/spring-ide/eclipse/updatesite/updatesite_1.0.0.zip.
> 
> Torsten 
> 
> 
> 
> __________________________________
> Do you Yahoo!?
> Yahoo! Small Business $15K Web Design Giveaway 
> http://promotions.yahoo.com/design_giveaway/
> 
> 
>
-------------------------------------------------------
> 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_id70&alloc_id638&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
>
https://lists.sourceforge.net/lists/listinfo/springframework-developer


__________________________________
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway 
http://promotions.yahoo.com/design_giveaway/

[Springframework-developer] sf connection problems?

[Keith D. <kd...@cs...>]

Has anyone besides me been having trouble connecting to the sourceforge
repository?
 
It frequently takes me 2 or 3 attempts to commit changes successfully.
Eclipse M8 often reports a "I/O error occured: connection reset" (or
something like that).  Or I get the wonderfully descriptive message "An
error has occured." :-)
 
It works eventually, don't get me wrong, my changes are sticking--it's just
a bit annoying. Keith

Re: [Springframework-developer] Spring IDE - Eclipse Plugin: Migration of SpringUI finished; Version 1.0.0 ready

[Nadeem B. <na...@ea...>]

Juergen, since you're a netbeans user, is there any chance of a netbeans
plugin?=20

regards,
Nadeem

On =BF=E5, 2004-04-07 at 15:52 +0200, j=8F=AB=E4rgen h=8F=AB=D3ller [werk3A=
T] wrote:

> Torsten,
>=20
> Ehm, (Eclipse newbie here), you want me to upload the updatesite zip as f=
ile release? Shouldn't it rather be some installation zip a la "spring-ide-=
eclipse.zip"? I guess I have to learn something about how Eclipse plugins a=
re distributed :-)=20
>=20
> Regarding the version number, we use "1.0" rather than "1.0.0" with the S=
pring distribution itself, so it's probably advisable to use the same numbe=
ring scheme with the Eclipse plugin.
>=20
> As we're about to release Spring 1.0.1 next week, I'd like to do the Ecli=
pse plugin 1.0 release in the same SourceForge upload session, and annouce =
both in the same mail. So there's still time to educate me in terms of Ecli=
pse plugin distributions ;-)
>=20
> Juergen
>=20
>=20
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On Behalf
> Of Torsten Juergeleit
> Sent: Monday, April 05, 2004 10:43 PM
> To: spr...@li...
> Subject: [Springframework-developer] Spring IDE - Eclipse Plugin:
> Migration of SpringUI finished; Version 1.0.0 ready
>=20
>=20
> I finished migrating the SpringUI Eclipse plugin into
> the Spring CVS (new module 'spring-ide/eclipse/').
>=20
> Now I am looking for a place to host the Eclipse
> plugin's update site (web site with a config XML file
> and two folders holding the plugin data). The update
> site is used by Eclipse's update manager to download
> different versions of the plugin directly from with
> the IDE. Also an HTML file and a few screen copies
> (with some infos about the plugin and it's update
> site) has to be hosted somewhere.
>=20
> To give an example I have stored the stuff in Spring's
> (unused) webspace on SF.NET. The installation infos
> can be found on=20
> http://springframework.sourceforge.net/spring-ide/eclipse/
> and the update site is available from
> http://springframework.sourceforge.net/spring-ide/eclipse/updatesite/.
>=20
>=20
> Does it make sense to host the plugin's update site
> and the corresponding HTML page on
> http://www.springframework.org/ or is SF.NET ok (the
> download of the Spring framework itself is hosted on
> SF.NET too)?
>=20
>=20
> J=8F=AB=E4rgen, you can create a file release on SF.NET for
> the plugin, if you like. The corresponding archive
> with version 1.0.0 of the plugin's update site is
> available from
> http://springframework.sourceforge.net/spring-ide/eclipse/updatesite/upda=
tesite_1.0.0.zip.
>=20
> Torsten=20
>=20
>=20
>=20
> __________________________________
> Do you Yahoo!?
> Yahoo! Small Business $15K Web Design Giveaway=20
> http://promotions.yahoo.com/design_giveaway/
>=20
>=20
> -------------------------------------------------------
> 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
>=20
>=20
> -------------------------------------------------------
> 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=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
--=20

Re: [Springframework-developer] Preparing for 1.0.1

[<tho...@tr...>]

My changes for 1.0.1 are ready to go:

Package org.springframework.jdbc.object
* added method setSqlReadyForUse to StoredProcedure for indicating that the sql
should be used as provided, no need to add parameter placeholders

Package org.springframework.jdbc.support
* changed SQLErrorCodesFactory, it now caches database product name in a Map
based on hashCode from DataSource to avoid unnecessary meta data lookups
* added an extractDatabaseMetaData method to JdbcUtils.  This change also adds
an interface named DatabaseMetaDataCallBackHandler that must be used for this
method

How do we want to proceed for 1.0.2 and 1.1.  Should we just add new features
and release what is stable for 1.0.2 or do we want to limit 1.0.2 to strictly
bug fixes and hold on to any enhancements until 1.1?

Thomas

Re: [Springframework-developer] Spring IDE - Eclipse Plugin: Migration of SpringUI finished; Version 1.0.0 ready

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

Torsten,

Ehm, (Eclipse newbie here), you want me to upload the updatesite zip as =
file release? Shouldn't it rather be some installation zip a la =
"spring-ide-eclipse.zip"? I guess I have to learn something about how =
Eclipse plugins are distributed :-)=20

Regarding the version number, we use "1.0" rather than "1.0.0" with the =
Spring distribution itself, so it's probably advisable to use the same =
numbering scheme with the Eclipse plugin.

As we're about to release Spring 1.0.1 next week, I'd like to do the =
Eclipse plugin 1.0 release in the same SourceForge upload session, and =
annouce both in the same mail. So there's still time to educate me in =
terms of Eclipse plugin distributions ;-)

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Torsten Juergeleit
Sent: Monday, April 05, 2004 10:43 PM
To: spr...@li...
Subject: [Springframework-developer] Spring IDE - Eclipse Plugin:
Migration of SpringUI finished; Version 1.0.0 ready


I finished migrating the SpringUI Eclipse plugin into
the Spring CVS (new module 'spring-ide/eclipse/').

Now I am looking for a place to host the Eclipse
plugin's update site (web site with a config XML file
and two folders holding the plugin data). The update
site is used by Eclipse's update manager to download
different versions of the plugin directly from with
the IDE. Also an HTML file and a few screen copies
(with some infos about the plugin and it's update
site) has to be hosted somewhere.

To give an example I have stored the stuff in Spring's
(unused) webspace on SF.NET. The installation infos
can be found on=20
http://springframework.sourceforge.net/spring-ide/eclipse/
and the update site is available from
http://springframework.sourceforge.net/spring-ide/eclipse/updatesite/.


Does it make sense to host the plugin's update site
and the corresponding HTML page on
http://www.springframework.org/ or is SF.NET ok (the
download of the Spring framework itself is hosted on
SF.NET too)?


J=FCrgen, you can create a file release on SF.NET for
the plugin, if you like. The corresponding archive
with version 1.0.0 of the plugin's update site is
available from
http://springframework.sourceforge.net/spring-ide/eclipse/updatesite/upda=
tesite_1.0.0.zip.

Torsten=20



__________________________________
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway=20
http://promotions.yahoo.com/design_giveaway/


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

Re: [Springframework-developer] Re: Struts Spring Plugin

[Lars H. <ho...@ar...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all,

Am 07.04.2004 um 04:48 schrieb Seth Ladd:

> Matt Raible wrote:
>> I'm in agreement with Don here.  I'm just looking for the 
>> best/easiest solution to integrate the two.  When I first looked at 
>> this plugin, I didn't like the fact that I had to declare my Action 
>> twice (once in struts-config.xml and once in applicationContext.xml). 
>>  However, the fact that I could use MockStrutsTestCase, as well as 
>> set my Managers declaratively on my Actions made me really like it.  
>> I'd like a minimal-intrusion mechanism, but I'm willing to do 
>> whatever you feel is best.  By minimal-intrusion, I mean I'd like to 
>> use an existing Action with very little or no changes - only some 
>> tweaking in an XML file.  I don't know if that's possible.
>
> I integrated Struts + Spring by creating a SpringRequestController and 
> overriding the createAction method to return from the Spring context.
>
> This is working really well for us, because no changes to our Actions. 
> We use xdoclet to make the struts-config, so we didn't want to use 
> Don's code.
>
> I passed this idea by Don, but he said this way isn't compatible w/ 
> Tiles, and something else possibly.  He definitely knows better than 
> I. :)

Agreed! I faced the same problem with SAIF. My first implementation 
ended up with two RequestProcessors: one default and one derived from 
TilesRequestProcessor. Unfortunately there is now real clean solution 
due to the bad design of the API. In order to "wrap" any possible other 
RequestController I ended up with using CGLIB ...

Yours,
Lars

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0.3

iQA/AwUBQHQAzLcyzbDWnRDCEQIrVwCgr0kcdGdnLwiajVvxoLnqhoXdomAAn1LZ
EHf/nNV86mQEb7THSSV038p5
=uwss
-----END PGP SIGNATURE-----

RE: [Springframework-developer] Creating documentation from Spring beans definition files (e.g. like HiveMind's HiveDoc)

[Torsten J. <tju...@ya...>]

Rod created an issue in JIRA
(http://opensource.atlassian.com/projects/spring/browse/SPR-87
) for this topic. Darren already added some
requirements.

We should use this JIRA issue to keep track on
additional requirements, design infos and source code
like the stylesheets provided by Daniel and Don.

Torsten

--- Faizan Hussain <fa...@ru...> wrote:
> Guys,
> I might be able to help you in writing xsl
> stylesheets for spring configs.
> It will be great if you can provide/explain the
> desired output for a
> particular xml file. 
> 
> If Daniel can also send me the xsl file that he
> mentioned that will also be
> a help.
> 
> Faizan 
> 
> 
> -----Original Message-----
> From:
>
spr...@li...
>
[mailto:spr...@li...]
> On Behalf Of
> Daniel Potter
> Sent: Tuesday, April 06, 2004 11:10 AM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Creating
> documentation from Spring
> beans definition files (e.g. like HiveMind's
> HiveDoc)
> 
> I know it's not quite what you had in mind with this
> question, but we've
> used Graphviz
> (www.research.att.com/sw/tools/graphviz/) to
> generate dependency graphs based on Spring
> configuration files.  The
> basic process involves using an XSL stylesheet to
> transform the Spring
> XML config files into the .dot syntax used by
> Graphviz, then running
> Graphviz on the .dot files to generate png, gif,
> postscript, etc.
> dependency graphs.  Of course, this wouldn't work
> for autowired
> configurations, but it generates interesting and
> useful graphs for
> explicit configurations.
> 
> Daniel
> 
> On Tue, Apr 06, 2004 at 01:02:39AM -0700, Torsten
> Juergeleit wrote:
> > Is anyone already working on a way to create
> > documentation from Spring beans definition files?
> > 
> > Howard's HiveMind / HiveDoc
> > (http://jakarta.apache.org/hivemind/hivedoc.html)
> uses
> > XSL stylesheets to transform the HiveMind config
> files
> > into a set of HTML files. Sample output:
> >
>
http://jakarta.apache.org/hivemind/hivedocs/index.html
> > 
> > Does it make sense to create something similar for
> > Spring?
> > 
> > Torsten


__________________________________
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway 
http://promotions.yahoo.com/design_giveaway/

[Springframework-developer] RE: commons-validator adapter

[Daniel M. <mi...@pa...>]

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