springframework-developer

[Springframework-developer] Current release plan

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

I haven't seen this addressed recently, so I'm just curious on the current
status.  The most recent "detailed" info I could find was from Juergen's
email on June 25
(http://sourceforge.net/mailarchive/message.php?msg_id=5357667), just before
the 0.9 release.  I have a few questions, partly to figure out if there's
anything I'll be able to help with now (before September :) ) and also to
gauge what to use for a project I'm starting.  Anyway, here's my list of
questions :)

1. What still needs to be done for 0.9.1.  From that list, what is currently
"assigned" to someone and what still needs help?
2. Same as #1 but for the 1.0 release.
3. What is the target time-frame for the 0.9.1 and 1.0 releases (obviously
this is sketchy since it's "volunteer" work, but "gut guesses" - probably
from Juergen :) - based on work left is what I'm hoping for.  The previous
estimate was the 1.0RC1 by now.
4. From Juergen's email which I referenced, it states "As far as I see, we
don't need additional functionality for 1.0".  The main thing holding me
back from adopting the current code base (I'm currently using a
personally-modified version of 0.8) is the amount and frequency of changes
to core functionality and the public api.  Some new features or minor bug
fixes are ok/normal, but these sweeping changes are destructive to
production code.  How close are we to finalizing the public api and the core
code?  Is it likely that these major changes should be done for 0.9.1?

To expand on my fourth question with a recommendation (hopefully it makes
sense to everyone).  If possible we should finalize the public api for
version 0.9.1 rather than at the 1.0RC1.  This will allow usage in new
development without fear of incompatibilities in the next couple months.
Personally this means I can use the current code base for development which
will benefit me with the new features and bug fixes, it would benefit Spring
by additional testing and use, and (on a personal note) it would allow me to
start contributing again sooner (I don't have "spare time" until September,
but I can use some "work time" once I'm using the current Spring version
rather than 0.8).  I believe I'm not alone in this, so hopefully a "mostly
finalized" core will attract a bunch of new developers (either users or
contributors) as well.  Obviously this finalization would allow changes
where required due to major gaffes and bugs (which I don't expect there will
be too many of, but there's always some :) ).

Trevor D. Cook

RE: [Springframework-developer] Current release plan

[Alef A. \(JTeam\) <al...@jt...>]

I read Juergen's mail and saw the following passage: ...and provide
short essays on resource/transaction management and Spring web MVC vs
Struts (as announced, I already have drafts).

Today I introduced one of our developers to Spring, because he needs to
take over things when I'm on a holiday (next two weeks) and he had major
difficulties in seeing when what methods are called in the controller
stuff. Especially the formcontroller classes are pretty hard with only
the JavaDoc. I'll be providing extending the JavaDoc of those classes a
bit more, since I haven't got anything to do anyway before this weekend
(that's new for me, and it's wonderful ;-). Something like a
sequence-diagram or something might be useful (but then in JavaDoc) and
small configuration-snippets and usage-example...

As far as additions to the MVC are concerned, I don't think much is
needed to be able to build a decent webapp. Anybody interested in
getting the TilesView(Resolver) in before the 1.0 release (might be a
nice feature to show the pluggability and stuff)??

Alef Arendsen



-----Oorspronkelijk bericht-----
Van: spr...@li...
[mailto:spr...@li...] Namens
Trevor Cook
Verzonden: Wednesday, July 30, 2003 9:24 PM
Aan: Spring Developers
Onderwerp: [Springframework-developer] Current release plan


I haven't seen this addressed recently, so I'm just curious on the
current status.  The most recent "detailed" info I could find was from
Juergen's email on June 25
(http://sourceforge.net/mailarchive/message.php?msg_id=5357667), just
before the 0.9 release.  I have a few questions, partly to figure out if
there's anything I'll be able to help with now (before September :) )
and also to gauge what to use for a project I'm starting.  Anyway,
here's my list of questions :)

1. What still needs to be done for 0.9.1.  From that list, what is
currently "assigned" to someone and what still needs help? 2. Same as #1
but for the 1.0 release. 3. What is the target time-frame for the 0.9.1
and 1.0 releases (obviously this is sketchy since it's "volunteer" work,
but "gut guesses" - probably from Juergen :) - based on work left is
what I'm hoping for.  The previous estimate was the 1.0RC1 by now. 4.
From Juergen's email which I referenced, it states "As far as I see, we
don't need additional functionality for 1.0".  The main thing holding me
back from adopting the current code base (I'm currently using a
personally-modified version of 0.8) is the amount and frequency of
changes to core functionality and the public api.  Some new features or
minor bug fixes are ok/normal, but these sweeping changes are
destructive to production code.  How close are we to finalizing the
public api and the core code?  Is it likely that these major changes
should be done for 0.9.1?

To expand on my fourth question with a recommendation (hopefully it
makes sense to everyone).  If possible we should finalize the public api
for version 0.9.1 rather than at the 1.0RC1.  This will allow usage in
new development without fear of incompatibilities in the next couple
months. Personally this means I can use the current code base for
development which will benefit me with the new features and bug fixes,
it would benefit Spring by additional testing and use, and (on a
personal note) it would allow me to start contributing again sooner (I
don't have "spare time" until September, but I can use some "work time"
once I'm using the current Spring version rather than 0.8).  I believe
I'm not alone in this, so hopefully a "mostly finalized" core will
attract a bunch of new developers (either users or
contributors) as well.  Obviously this finalization would allow changes
where required due to major gaffes and bugs (which I don't expect there
will be too many of, but there's always some :) ).

Trevor D. Cook



-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01
/01
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] forms

[Ken K. <kk...@kk...>]

Alef,


Alef Arendsen (JTeam) wrote:

>...
>
>Today I introduced one of our developers to Spring, because he needs to
>take over things when I'm on a holiday (next two weeks) and he had major
>difficulties in seeing when what methods are called in the controller
>stuff. Especially the formcontroller classes are pretty hard with only
>the JavaDoc. I'll be providing extending the JavaDoc of those classes a
>bit more, since I haven't got anything to do anyway before this weekend
>(that's new for me, and it's wonderful ;-). Something like a
>sequence-diagram or something might be useful (but then in JavaDoc) and
>small configuration-snippets and usage-example...
>
It is a complex process. I struggled greatly with this while working on 
Petclinic.

It's far from a complete picture, but there is some information on 
formcontrollers in the Petclinic tutorial.html file you may find useful.
See the heading "Controllers". The Petclinic forms show simple examples 
of some useful techniques.

I would also suggest looking in particular at  the source code for :
- the handleRequestInternal method in AbstractFormController
- the bindAndValidate method in BaseCommandController.

Hope this helps.

Ken

RE: [Springframework-developer] forms

[Alef A. \(JTeam\) <al...@jt...>]

Thanks Ken,

Those are exactly the things I had a look at as well when I started
using them. The only problem was that particular developer and to
getting him to understand things as well. He's like this Javadoc kind of
guy (and he's absolutely right!) and that's where the problem is
(somewhat) when it comes to those classes... Well, I've already added
some javadoc and will do some more anyway...

Alef

-----Oorspronkelijk bericht-----
Van: Ken Krebs [mailto:kk...@kk...] 
Verzonden: Wednesday, July 30, 2003 11:18 PM
Aan: al...@jt...
CC: 'Spring Developers'
Onderwerp: Re: [Springframework-developer] forms


Alef,


Alef Arendsen (JTeam) wrote:

>...
>
>Today I introduced one of our developers to Spring, because he needs to

>take over things when I'm on a holiday (next two weeks) and he had 
>major difficulties in seeing when what methods are called in the 
>controller stuff. Especially the formcontroller classes are pretty hard

>with only the JavaDoc. I'll be providing extending the JavaDoc of those

>classes a bit more, since I haven't got anything to do anyway before 
>this weekend (that's new for me, and it's wonderful ;-). Something like

>a sequence-diagram or something might be useful (but then in JavaDoc) 
>and small configuration-snippets and usage-example...
>
It is a complex process. I struggled greatly with this while working on 
Petclinic.

It's far from a complete picture, but there is some information on 
formcontrollers in the Petclinic tutorial.html file you may find useful.
See the heading "Controllers". The Petclinic forms show simple examples 
of some useful techniques.

I would also suggest looking in particular at  the source code for :
- the handleRequestInternal method in AbstractFormController
- the bindAndValidate method in BaseCommandController.

Hope this helps.

Ken

Re: [Springframework-developer] Current release plan

[Tarjei S. <lo...@on...>]

On Wed, Jul 30, 2003 at 10:41:04PM +0200, Alef Arendsen (JTeam) wrote:
[..]
> As far as additions to the MVC are concerned, I don't think much is
> needed to be able to build a decent webapp. Anybody interested in
> getting the TilesView(Resolver) in before the 1.0 release (might be a
> nice feature to show the pluggability and stuff)??

I'm very interested in getting at least TilesView in before 1.0. I'm
using Tiles myself for most of my own personal projects and I find it
highly useful. I've spent some time lately looking at the TilesView and
TilesViewResolver you posted a couple of weeks ago. TilesView seemed to
work quite ok, definitely something that could be included in Spring
imho :)

When it comes to the TilesViewResolver I'm not quite so sure, it doesn't
seem quite right in my opinion. I would much rather see an aproach like
the one we currently have for Velocity. The TilesViewResolver you posted
didn't really do anything specifically related to resolving the view, 
it more or less just took care of initializing the DefinitionsFactory for 
Tiles. 

I'd like to propose that TilesViewResolver should be renamed to
something like TilesConfigurer. TilesConfigurer would just be a simple
javabean that takes care of initializing Tiles, just like
VelocityConfigurer currently does for Velocity. TilesView would be
pretty much the same as before, maybe we could add a definitionName
property that gives the user a possibility to not use the view name as
the definition name all of the time. We could default to using the
viewname as the definitionname to minimize the need for aditional 
configration for each TilesView but allow the developers out there to 
override it if needed.

--
Tarjei Skorgenes
lo...@on...

Re: [Springframework-developer] Current release plan

[<tri...@tr...>]

Trevor & All,

> 1. What still needs to be done for 0.9.1.  From that list, what is currently
> "assigned" to someone and what still needs help?

I have nothing additional.

> 2. Same as #1 but for the 1.0 release.

I'll be adding functionality to the JDBC package.  Returning resultset from a
stored procedure is the main addition.  This should all be additional
functionality and not break the existing API.

> 3. What is the target time-frame for the 0.9.1 and 1.0 releases (obviously
> this is sketchy since it's "volunteer" work, but "gut guesses" - probably
> from Juergen :) - based on work left is what I'm hoping for.  The previous
> estimate was the 1.0RC1 by now.

Once 0.9.1 is out (any day now AFAIK), I would suggest a 4-6 weeks "beta"
testing period.  I'm hoping to use parts of the framework in new projects the
next couple of months.  Tha would put the 1.0 release somewhere in September.

> 
> To expand on my fourth question with a recommendation (hopefully it makes
> sense to everyone).  If possible we should finalize the public api for
> version 0.9.1 rather than at the 1.0RC1.  This will allow usage in new
> development without fear of incompatibilities in the next couple months.

100% agreement - I'm pretty much in the same boat.  If we keep the API stable I
can start using it on new development.

Thomas