RE: [Springframework-developer] 1.0 M3 prepared

[Trevor C. <pr...@se...>]

I've updated our projects to M3, and everything is working properly now.

I did have a slight problem with a few places where I overrided userObjec=
t
(in the SimpleFormController) but no compilation errors were reported (th=
is
took a while to track down).  While the public api won't be frozen until =
the
RC, can I request that any changes to the public apis (method name change=
s
and parameter signatures) are done using the @deprecated tag, and the
deprecated method simply calls the new method.  This will ensure that the
compiler will report problems rather than things compiling ok and failing
properly.  I know Juergen has been doing this with many recent changes, b=
ut
an "across-the-board" policy would make things easier now that the size o=
f
Spring's code and my own has grown so large.  These deprecations can be
removed for the RC (possibly by creating an M4 first with deprecations st=
ill
in, and then an RC immediately with the deprecations removed for the "fin=
al"
public api).

+1 to including source but no libs with samples

Trevor

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of j=FCrgen h=F6ller [werk3AT]
Sent: November 22, 2003 7:45 PM
To: spr...@li...
Subject: Re: [Springframework-developer] 1.0 M3 prepared


FYI, I've already committed the renaming from ListableBeanFactoryImpl to
DefaultListableBeanFactory. The web MVC exception stuff will follow
tomorrow.

I've also reworked the Tiles example, using
org.springframework.samples.tiles as package now, and auto-detecting the
Tiles DTD. The FileNameViewController has now moved to
org.springframework.web.servlet.mvc. And I've changed my mind: I do like =
to
include struts-1.1.jar and commons-digester.jar now, for an out-of-the-bo=
x
working example. It already annoys me having to copy those files in for
testing, so consider a new user...

I've just modified our build script to generate two release zips:
spring-framework-1.0-m3.zip (~5600 KB) and
spring-framework-1.0-m3-samples.zip (~5400 KB). Both use
spring-framework-1.0-m3 as path in the zip, for convenient extraction to =
the
same location. The former contains dist, docs, lib/aop-alliance,
lib/jakarta-commons/commons-logging.jar, src, and the readmes, while the
latter contains samples and the additional libs necessary for building an=
d
running them.

What do you think? Should I commit the changed build script and use it fo=
r
the M3 release? I believe it would make sense to split the release into
those two files, as 11 MB is already a bit large for a single distributio=
n.

Juergen


________________________________

Von: spr...@li... im Auftrag von
Colin Sampaleanu
Gesendet: Sa 22.11.2003 00:57
An: spr...@li...
Betreff: Re: [Springframework-developer] 1.0 M3 prepared



j=FCrgen h=F6ller [werk3AT] wrote:

>Everybody,
>
>I've just prepared the release as far as possible: fixed all javadoc
errors, added missing package javadocs, tested the samples. All tests for
shipped components pass on my machine (when running via Ant).
>
>The TLD is now loaded from the spring.jar file, referenced via the defau=
lt
URI http://www.springframework.org/tags (analogous to Struts and JSTL).
BaseCommandController uses setCommandName now, with setBeanName being
deprecated.
>
>Whoever wants to give it a try, fetch the latest CVS contents, run the
release target, and "play user" with spring-framework-1.0-m3.zip (it's in
the target/release directrory): unzip it, browse through the docs, build =
the
sample wars (call ant warfile or warfile.bat) and drop them into your
container's webapps directory.
>
>Alef, could you give the tiles-example a final try? I'm not keen on
including struts.jar in the Spring distribution, so the example should be
prepared for deployment with a manually added struts.jar.
>
>A final note on a further naming issue: I'm not entirely happy with
"ListableBeanFactoryImpl". For example, BeanWrapperImpl is *the*
implementation of BeanWrapper, hardly any chance for alternative
implementations - the interface is rather a simplified API for it. But
ListableBeanFactoryImpl implements ConfigurableListableBeanFactory with
registration methods for a specific properties format; this seems to be a
different case to me.
>
>So wouldn't it be more appropriate to call it "DefaultListableBeanFactor=
y"?
That name change should not affect typical applications anyway but just
"power users" who should be willing to migrate via a simple class name
change. I quite strongly prefer this name to "ListableBeanFactoryImpl",
actually. If we agree on the new name, let's better change it now instead=
 of
in the 1.0 RC phase.
>
>
>
I am ok with the name change, as it does make sense.

Btw, as per another email, I have added a new MethodCallFactoryBean
class. It should be totally ok for this release, as no other code was
touched, and there is a full unit test.

Regards,
Colin




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer