You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by ma...@tumbleweed.com on 2001/11/05 06:09:04 UTC
Future Struts releases
It seems to me that we have reached the point where a sufficient number of
bugs have been fixed since Struts 1.0 to warrant the release of a Struts
1.0.1 patch. This will allow people to move on to a released version of
Struts to obtain these fixes, rather than having to build their own version
from the branch sources.
In addition, a lot has happened on the main trunk (nightly builds) since the
Struts 1.0 release. There have been many bug fixes, and there is substantial
new functionality. Looking at the ToDo list, however, it seems likely that
it will be quite some time before all of the functionality listed there will
be implemented, or even just the items for which volunteers are listed.
Again, in order to bring the new functionality to developers sooner, I
propose that we consider the release of a Struts 1.1 version in an earlier
timeframe. Struts 1.1 would not include all the proposed items on the ToDo
list, but rather a slimmed down list which we agree upon, and which we
believe can be completed in the relatively near term. The remaining items
would be incorporated in a later release (1.2 or 2.0).
Comments?
--
Martin Cooper
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Future Struts releases
Posted by Ted Husted <hu...@apache.org>.
Going over the release notes, we would have the following "punchlist"
for a 1.1 release
+ Commons Packages
+ Jaxp 1.1
+ Unit Testing
+ ActionMessages
+ Indexed tags
+ logic:empty
+ Various fixes and refinements
which seems sufficient. (Heck, just the indexed tags would be sufficient
;-)
I'd like to make Tiles, ValidatorForm, and maybe Nik Hobb's Role Based
Actions to play a bigger role in a future release. But this might be
best done in cooperation with the ServiceManager, or equivalent. These
are easy enough to plug in now. Maybe there could be a way to bundled
these in as separate downloads.
So, I'd be +1 on someone proposing release plan at point.
If someone is in there, we should probably add Declarative Exceptions to
the TODO list, or do we want to try and slip that in now.
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel +1 716 737-3463
-- http://www.husted.com/struts/
martin.cooper@tumbleweed.com wrote:
>
> It seems to me that we have reached the point where a sufficient number of
> bugs have been fixed since Struts 1.0 to warrant the release of a Struts
> 1.0.1 patch. This will allow people to move on to a released version of
> Struts to obtain these fixes, rather than having to build their own version
> from the branch sources.
>
> In addition, a lot has happened on the main trunk (nightly builds) since the
> Struts 1.0 release. There have been many bug fixes, and there is substantial
> new functionality. Looking at the ToDo list, however, it seems likely that
> it will be quite some time before all of the functionality listed there will
> be implemented, or even just the items for which volunteers are listed.
>
> Again, in order to bring the new functionality to developers sooner, I
> propose that we consider the release of a Struts 1.1 version in an earlier
> timeframe. Struts 1.1 would not include all the proposed items on the ToDo
> list, but rather a slimmed down list which we agree upon, and which we
> believe can be completed in the relatively near term. The remaining items
> would be incorporated in a later release (1.2 or 2.0).
>
> Comments?
>
> --
> Martin Cooper
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Future Struts releases
Posted by Ted Husted <hu...@apache.org>.
Ted Husted wrote:
> [Tiles,Validator]
>
> The next question is whether David and Cedric are interested in
> proposing their components to Taglibs or the Commons, or would prefer to
> leave them here. Your call, guys. I believe that you have both indicated
> an interest in broadening the audience for this components, so I say go
> for it. Of course, we would add both to the Users Guide, and may even
> end up requiring the JARs as we do for the Commons components.
Ooops, see that David started that process already. Just tossed his
proposal my binding +1 on the Commons list.
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel +1 716 737-3463
-- http://www.husted.com/struts/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Future Struts releases
Posted by Cedric Dumoulin <ce...@lifl.fr>.
Ted Husted wrote:
> So, now that 1.0.1 is in the queue, we may want to make some decisions
> regarding 1.1.
>
> ...
>
> [Tiles,Validator]
>
> The next question is whether David and Cedric are interested in
> proposing their components to Taglibs or the Commons, or would prefer to
> leave them here. Your call, guys. I believe that you have both indicated
> an interest in broadening the audience for this components, so I say go
> for it. Of course, we would add both to the Users Guide, and may even
> end up requiring the JARs as we do for the Commons components.
I will propose Tiles to taglibs, but, as already said, I would like to let in
Struts an example combining Struts and Tiles. This example will replace actual
example/distribution.
I am in the process of finalizing a new version, with the example.
>
>
> [JARs]
>
> How do people feel about making the rest of the Struts JARs more
> granular? Maybe we should be breaking this up so each package or taglib
> gets its own JAR, so we could have
>
> struts-action.jar
> struts-actions.jar
> struts-html.jar
> struts-logic.jar
> struts-bean.jar
> struts-template.jar
> struts-upload.jar
> struts-util.jar
>
> I think the general trend is toward finely-grained JARs. Down the road,
> I could envision people using the struts-action.jar, but not needing any
> (or all of) the taglibs.
>
We should find the right boundary between too big or too small jar files ...
If there is too much jar files, people won't remind from where a functionality
comes, or what are jar dependencies. As a result, they will use systematically
all jar files ...
Cedric
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Future Struts releases
Posted by Ted Husted <hu...@apache.org>.
So, now that 1.0.1 is in the queue, we may want to make some decisions
regarding 1.1.
[taglibs]
Personally, I think the existing changes to the tags along probably
justify a release on their own. Though, we need to add some
documentation there. Arron's nested taglib looks pretty cool, and I'd
like to slip that in too.
[Tiles,Validator]
The next question is whether David and Cedric are interested in
proposing their components to Taglibs or the Commons, or would prefer to
leave them here. Your call, guys. I believe that you have both indicated
an interest in broadening the audience for this components, so I say go
for it. Of course, we would add both to the Users Guide, and may even
end up requiring the JARs as we do for the Commons components.
[JARs]
How do people feel about making the rest of the Struts JARs more
granular? Maybe we should be breaking this up so each package or taglib
gets its own JAR, so we could have
struts-action.jar
struts-actions.jar
struts-html.jar
struts-logic.jar
struts-bean.jar
struts-template.jar
struts-upload.jar
struts-util.jar
I think the general trend is toward finely-grained JARs. Down the road,
I could envision people using the struts-action.jar, but not needing any
(or all of) the taglibs.
[Role-Based Actions]
I'm going to try and get Nic Hobb's security package in play next week
http://husted.com/struts/resources/struts-security.htm
and if it lives up to its reputation, I would probably want to commit
it. Would anyone have any qualms with this?
[Declarative Exceptions]
Any ideas about how we could put this into play using its own signature
(throwing Exception) and still support the original signature. I like
the idea, but I would also like to do it right. This won't be the last
time a problem with changing signatures comes up. There would be ways to
do it using a different base Action, but that gets messy as a standard
approach.
This might be a 1.2 issue anyway, since there hasn't been a working
package out there for people to use.
Now that Martin's tapped the keg, we might start thinking in terms of
more rapid releases.
We might even start taking notes on a Struts 2.0, that might make
changes that would be a Good Thing, but would break too much of the 1.0
base. Many of the class names comes to mind ;-) I mean how many things
can we call "Action" anyway ;-) The 2.0 codebase might also leverage
filters and other new technologies.
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel +1 716 737-3463
-- http://www.husted.com/struts/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Future Struts releases
Posted by Petr Jiricka <pe...@czech.sun.com>.
----- Original Message -----
From: "James Holmes" <jh...@yahoo.com>
To: "Struts Developers List" <st...@jakarta.apache.org>
Sent: Monday, November 05, 2001 4:50 PM
Subject: Re: Future Struts releases
[snip]
> >
> > So, are you still thinking about taking the Console
> > open source?
>
> I'd certainly like to do so and see it part of the
> standard distribution or at least start out by adding
> it to the contrib folder and have me work from that
> repository. I have talked some with Petr Jiricka from
> the NetBeans project and would like to perhaps
> coordinate with him on getting it included as a
> standard module there too. I saw something there a
> couple of weeks ago where they wanted some kind of
> Struts support for NB4. Petr, comments?
Well, I think it would definitely be beneficial to have Struts support in
NetBeans, however at this point Sun can not dedicate any resources for this.
So the Struts Console would fit perfectly into this.
>I personally
> would ultimately like to see the Struts Console
> packaged with the standard Struts distribution as an
> all encompassing development/management tool. I'd
> also like to see it packaged with the standard
> NetBeans/Forte distributions. I think this would go a
> long way in helping the proliferation of Struts.
I agree that inclusion in NetBeans would be very useful, though I doubt we
can convince Sun to include it in Forte for Java.
Petr
>
> With that said, what are the next steps? If the
> Struts group is interested would we put the code into
> CVS along with other Jakarta projects and give me
> commit access?
>
> -james
> james@jamesholmes.com
> http://jamesholmes.com/struts/
>
> > -- Ted Husted, Husted dot Com, Fairport NY USA.
> > -- Custom Software ~ Technical Services.
> > -- Tel +1 716 737-3463
> > -- http://www.husted.com/struts/
> >
> >
> >
> > James Holmes wrote:
> > >
> > > For what it's worth, I'm +1.
> > >
> > > A few things...
> > >
> > > 1.) Any thoughts on including my patch for
> > allowing
> > > for multiple config files for 1.1? The patches
> > are
> > > available at http://jamesholmes.com/struts/. This
> > is
> > > a small patch and should help large development
> > teams
> > > out a great deal.
> > >
> > > 2.) Any thoughts on updating the Struts
> > configuration
> > > file DTD to have a different root element (ie.
> > > <struts>). I think including it in 1.1 would be a
> > > good idea if we plan to do this. Doing it sooner
> > > rather than later would make adding in new tags in
> > the
> > > future easier and would shield us (hopefully) from
> > > future config file incompatibilities. I would be
> > > happy to provide a patch for this.
> > >
> > > 3.) We've mentioned briefly the desire for their
> > to be
> > > warning messages when config files have
> > "conflicting"
> > > elements. Any thoughts on this? I'd be happy to
> > > provide patches for 1.0.1 and/or 1.1.
> > >
> > > Finally, if there's any loose ends out there for
> > > getting the new releases out that someone doesn't
> > have
> > > time for I have some bandwidth and can help.
> > >
> > > Thanks,
> > >
> > > -james
> > > james@jamesholmes.com
> > > http://www.jamesholmes.com/struts/
> > >
> > > --- martin.cooper@tumbleweed.com wrote:
> > > > It seems to me that we have reached the point
> > where
> > > > a sufficient number of
> > > > bugs have been fixed since Struts 1.0 to warrant
> > the
> > > > release of a Struts
> > > > 1.0.1 patch. This will allow people to move on
> > to a
> > > > released version of
> > > > Struts to obtain these fixes, rather than having
> > to
> > > > build their own version
> > > > from the branch sources.
> > > >
> > > > In addition, a lot has happened on the main
> > trunk
> > > > (nightly builds) since the
> > > > Struts 1.0 release. There have been many bug
> > fixes,
> > > > and there is substantial
> > > > new functionality. Looking at the ToDo list,
> > > > however, it seems likely that
> > > > it will be quite some time before all of the
> > > > functionality listed there will
> > > > be implemented, or even just the items for which
> > > > volunteers are listed.
> > > >
> > > > Again, in order to bring the new functionality
> > to
> > > > developers sooner, I
> > > > propose that we consider the release of a Struts
> > 1.1
> > > > version in an earlier
> > > > timeframe. Struts 1.1 would not include all the
> > > > proposed items on the ToDo
> > > > list, but rather a slimmed down list which we
> > agree
> > > > upon, and which we
> > > > believe can be completed in the relatively near
> > > > term. The remaining items
> > > > would be incorporated in a later release (1.2 or
> > > > 2.0).
> > > >
> > > > Comments?
> > > >
> > > > --
> > > > Martin Cooper
> > > >
> > > >
> > > >
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > > >
> > <ma...@jakarta.apache.org>
> > > > For additional commands, e-mail:
> > > > <ma...@jakarta.apache.org>
> > > >
> > >
> > > __________________________________________________
> > > Do You Yahoo!?
> > > Find a job, post your resume.
> > > http://careers.yahoo.com
> > >
> > > --
> > > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
> > --
> > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
>
>
> __________________________________________________
> Do You Yahoo!?
> Find a job, post your resume.
> http://careers.yahoo.com
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Future Struts releases
Posted by James Holmes <jh...@yahoo.com>.
Comments are inline...
--- Ted Husted <hu...@apache.org> wrote:
> I like the idea of changing the DTD to use a
> different root elements,
> and thereby accept multiple <struts-config>
> elements. But don't think we
> should get into that for 1.1 now.
Fair enough. It would certainly be late in the game
to introduce this now if we are going to release 1.1
imminently. I can work up a patch and we'll apply it
when it's "safe".
Also, my thinking behind this was not necessarily to
support multiple <struts-config> elements (great idea
though), but more along the lines of adding other
"stuff" into the main config file. For instance,
support for validation and message resources as you
(Ted) had mentioned in an earlier thread.
> I'm also hesitant to to commit to an approach to
> multiple Struts-config
> until we have changed the DTD, and had this solution
> out in the field a
> little longer.
Agreed.
> How about if we offer an alternative standard
> ActionServlet that offers
> this patch by overriding initMap?
Sounds like a good idea. This would certainly allow
the functionality to get more exposure. My feeling is
that most people would be more comfortable with using
this in production environments if it was packaged
with the standard distribution versus having to patch
the source and compile it in.
What should we call the "extended" servlet?
ActionServlet2? ActionServletX (eXtended
functionality)? ActionServetletExtended?
> This will help get it out there, while we finish the
> job on the DTD.
Exactly.
> If any unforeseen problems surface, people can just
> switch batch and
> paste their configs back together.
>
> AFAIK, whatever there may be to do is in Bugzilla or
> on the TODO list.
>
> So, are you still thinking about taking the Console
> open source?
I'd certainly like to do so and see it part of the
standard distribution or at least start out by adding
it to the contrib folder and have me work from that
repository. I have talked some with Petr Jiricka from
the NetBeans project and would like to perhaps
coordinate with him on getting it included as a
standard module there too. I saw something there a
couple of weeks ago where they wanted some kind of
Struts support for NB4. Petr, comments? I personally
would ultimately like to see the Struts Console
packaged with the standard Struts distribution as an
all encompassing development/management tool. I'd
also like to see it packaged with the standard
NetBeans/Forte distributions. I think this would go a
long way in helping the proliferation of Struts.
With that said, what are the next steps? If the
Struts group is interested would we put the code into
CVS along with other Jakarta projects and give me
commit access?
-james
james@jamesholmes.com
http://jamesholmes.com/struts/
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Custom Software ~ Technical Services.
> -- Tel +1 716 737-3463
> -- http://www.husted.com/struts/
>
>
>
> James Holmes wrote:
> >
> > For what it's worth, I'm +1.
> >
> > A few things...
> >
> > 1.) Any thoughts on including my patch for
> allowing
> > for multiple config files for 1.1? The patches
> are
> > available at http://jamesholmes.com/struts/. This
> is
> > a small patch and should help large development
> teams
> > out a great deal.
> >
> > 2.) Any thoughts on updating the Struts
> configuration
> > file DTD to have a different root element (ie.
> > <struts>). I think including it in 1.1 would be a
> > good idea if we plan to do this. Doing it sooner
> > rather than later would make adding in new tags in
> the
> > future easier and would shield us (hopefully) from
> > future config file incompatibilities. I would be
> > happy to provide a patch for this.
> >
> > 3.) We've mentioned briefly the desire for their
> to be
> > warning messages when config files have
> "conflicting"
> > elements. Any thoughts on this? I'd be happy to
> > provide patches for 1.0.1 and/or 1.1.
> >
> > Finally, if there's any loose ends out there for
> > getting the new releases out that someone doesn't
> have
> > time for I have some bandwidth and can help.
> >
> > Thanks,
> >
> > -james
> > james@jamesholmes.com
> > http://www.jamesholmes.com/struts/
> >
> > --- martin.cooper@tumbleweed.com wrote:
> > > It seems to me that we have reached the point
> where
> > > a sufficient number of
> > > bugs have been fixed since Struts 1.0 to warrant
> the
> > > release of a Struts
> > > 1.0.1 patch. This will allow people to move on
> to a
> > > released version of
> > > Struts to obtain these fixes, rather than having
> to
> > > build their own version
> > > from the branch sources.
> > >
> > > In addition, a lot has happened on the main
> trunk
> > > (nightly builds) since the
> > > Struts 1.0 release. There have been many bug
> fixes,
> > > and there is substantial
> > > new functionality. Looking at the ToDo list,
> > > however, it seems likely that
> > > it will be quite some time before all of the
> > > functionality listed there will
> > > be implemented, or even just the items for which
> > > volunteers are listed.
> > >
> > > Again, in order to bring the new functionality
> to
> > > developers sooner, I
> > > propose that we consider the release of a Struts
> 1.1
> > > version in an earlier
> > > timeframe. Struts 1.1 would not include all the
> > > proposed items on the ToDo
> > > list, but rather a slimmed down list which we
> agree
> > > upon, and which we
> > > believe can be completed in the relatively near
> > > term. The remaining items
> > > would be incorporated in a later release (1.2 or
> > > 2.0).
> > >
> > > Comments?
> > >
> > > --
> > > Martin Cooper
> > >
> > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > >
> <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> > > <ma...@jakarta.apache.org>
> > >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Find a job, post your resume.
> > http://careers.yahoo.com
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
__________________________________________________
Do You Yahoo!?
Find a job, post your resume.
http://careers.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Future Struts releases
Posted by Ted Husted <hu...@apache.org>.
I like the idea of changing the DTD to use a different root elements,
and thereby accept multiple <struts-config> elements. But don't think we
should get into that for 1.1 now.
I'm also hesitant to to commit to an approach to multiple Struts-config
until we have changed the DTD, and had this solution out in the field a
little longer.
How about if we offer an alternative standard ActionServlet that offers
this patch by overriding initMap?
This will help get it out there, while we finish the job on the DTD.
If any unforeseen problems surface, people can just switch batch and
paste their configs back together.
AFAIK, whatever there may be to do is in Bugzilla or on the TODO list.
So, are you still thinking about taking the Console open source?
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel +1 716 737-3463
-- http://www.husted.com/struts/
James Holmes wrote:
>
> For what it's worth, I'm +1.
>
> A few things...
>
> 1.) Any thoughts on including my patch for allowing
> for multiple config files for 1.1? The patches are
> available at http://jamesholmes.com/struts/. This is
> a small patch and should help large development teams
> out a great deal.
>
> 2.) Any thoughts on updating the Struts configuration
> file DTD to have a different root element (ie.
> <struts>). I think including it in 1.1 would be a
> good idea if we plan to do this. Doing it sooner
> rather than later would make adding in new tags in the
> future easier and would shield us (hopefully) from
> future config file incompatibilities. I would be
> happy to provide a patch for this.
>
> 3.) We've mentioned briefly the desire for their to be
> warning messages when config files have "conflicting"
> elements. Any thoughts on this? I'd be happy to
> provide patches for 1.0.1 and/or 1.1.
>
> Finally, if there's any loose ends out there for
> getting the new releases out that someone doesn't have
> time for I have some bandwidth and can help.
>
> Thanks,
>
> -james
> james@jamesholmes.com
> http://www.jamesholmes.com/struts/
>
> --- martin.cooper@tumbleweed.com wrote:
> > It seems to me that we have reached the point where
> > a sufficient number of
> > bugs have been fixed since Struts 1.0 to warrant the
> > release of a Struts
> > 1.0.1 patch. This will allow people to move on to a
> > released version of
> > Struts to obtain these fixes, rather than having to
> > build their own version
> > from the branch sources.
> >
> > In addition, a lot has happened on the main trunk
> > (nightly builds) since the
> > Struts 1.0 release. There have been many bug fixes,
> > and there is substantial
> > new functionality. Looking at the ToDo list,
> > however, it seems likely that
> > it will be quite some time before all of the
> > functionality listed there will
> > be implemented, or even just the items for which
> > volunteers are listed.
> >
> > Again, in order to bring the new functionality to
> > developers sooner, I
> > propose that we consider the release of a Struts 1.1
> > version in an earlier
> > timeframe. Struts 1.1 would not include all the
> > proposed items on the ToDo
> > list, but rather a slimmed down list which we agree
> > upon, and which we
> > believe can be completed in the relatively near
> > term. The remaining items
> > would be incorporated in a later release (1.2 or
> > 2.0).
> >
> > Comments?
> >
> > --
> > Martin Cooper
> >
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
>
> __________________________________________________
> Do You Yahoo!?
> Find a job, post your resume.
> http://careers.yahoo.com
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Future Struts releases
Posted by James Holmes <jh...@yahoo.com>.
For what it's worth, I'm +1.
A few things...
1.) Any thoughts on including my patch for allowing
for multiple config files for 1.1? The patches are
available at http://jamesholmes.com/struts/. This is
a small patch and should help large development teams
out a great deal.
2.) Any thoughts on updating the Struts configuration
file DTD to have a different root element (ie.
<struts>). I think including it in 1.1 would be a
good idea if we plan to do this. Doing it sooner
rather than later would make adding in new tags in the
future easier and would shield us (hopefully) from
future config file incompatibilities. I would be
happy to provide a patch for this.
3.) We've mentioned briefly the desire for their to be
warning messages when config files have "conflicting"
elements. Any thoughts on this? I'd be happy to
provide patches for 1.0.1 and/or 1.1.
Finally, if there's any loose ends out there for
getting the new releases out that someone doesn't have
time for I have some bandwidth and can help.
Thanks,
-james
james@jamesholmes.com
http://www.jamesholmes.com/struts/
--- martin.cooper@tumbleweed.com wrote:
> It seems to me that we have reached the point where
> a sufficient number of
> bugs have been fixed since Struts 1.0 to warrant the
> release of a Struts
> 1.0.1 patch. This will allow people to move on to a
> released version of
> Struts to obtain these fixes, rather than having to
> build their own version
> from the branch sources.
>
> In addition, a lot has happened on the main trunk
> (nightly builds) since the
> Struts 1.0 release. There have been many bug fixes,
> and there is substantial
> new functionality. Looking at the ToDo list,
> however, it seems likely that
> it will be quite some time before all of the
> functionality listed there will
> be implemented, or even just the items for which
> volunteers are listed.
>
> Again, in order to bring the new functionality to
> developers sooner, I
> propose that we consider the release of a Struts 1.1
> version in an earlier
> timeframe. Struts 1.1 would not include all the
> proposed items on the ToDo
> list, but rather a slimmed down list which we agree
> upon, and which we
> believe can be completed in the relatively near
> term. The remaining items
> would be incorporated in a later release (1.2 or
> 2.0).
>
> Comments?
>
> --
> Martin Cooper
>
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
__________________________________________________
Do You Yahoo!?
Find a job, post your resume.
http://careers.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>