RE: JIRA - Closing Releases
> -Original Message- > From: Paul Benedict [mailto:[EMAIL PROTECTED] > Sent: 20. august 2006 00:36 > To: Struts Developers List > Subject: JIRA - Closing Releases > > I am pleased to announce that Struts 0.5 in JIRA has been > released :) hehe. Everything looks good! I will release the > other versions now up to 1.3.4 so our JIRA roadmap looks up to date. Another small suggestion: You probably want to archive those really old ones as well. :) (Archived versions don't show up in versions-related combo boxes.) \Anders - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [s2] jira is down
> -Original Message- > From: Paul Benedict [mailto:[EMAIL PROTECTED] > Sent: 19. august 2006 23:06 > To: Struts Developers List > Subject: Re: [s2] jira is down > > Does releasing in JIRA actually send out emails for all the > bugs attached to it??? No, it does not. \Anders - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [s2] jira is down
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Ted Husted > Sent: 19. august 2006 22:03 > To: Struts Developers List > Subject: Re: [s2] jira is down > > On 8/19/06, Wendy Smoak <[EMAIL PROTECTED]> wrote: > > Before you do this, we probably need to coordinate and > switch Struts 1 > > to a new notification scheme that does not send email for every > > change. Can someone more familiar with JIRA config please comment? > > The simplest thing might be to turn off notifications > temporarily for Struts 1, and then turn it back on again. Or possibly even simpler, if you use bulk update you get to choose whether to send emails for the updates or not. \Anders - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Struts 1.3.5 Quality (re-vote)
+1 GA non-binding. Been using 1.3.5 successfully in my app. \Anders > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Ted Husted > Sent: 11. august 2006 15:07 > To: Struts Developers List > Subject: Re: [VOTE] Struts 1.3.5 Quality (re-vote) > > On 8/11/06, James Mitchell <[EMAIL PROTECTED]> wrote: > > +1 GA -- Looks great!!! > > LOL. No fair voting twice, James :) > > As it stands, we have two beta and two GA. > > Remember, everyone who has tested the distribution is invited > to vote, binding or not. > > -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Struts release timelines (Was: RE: [s2] Struts 2.0.0 - Tag it and Roll it?)
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Ted Husted > Sent: 25. juli 2006 00:45 > To: Struts Developers List > Subject: Re: [s2] Struts 2.0.0 - Tag it and Roll it? > > On 7/24/06, Anders Steinlein <[EMAIL PROTECTED]> wrote: > > > IMHO, all the users, including ourselves, are served best when we > > > release early and release often. > > > > Isn't this kind of ironic you repeating this over and over > again given > > the state of the 1.3 release? > > > > [...] > > I'd say it's effort to learn from history, lest we be doomed > to repeat it. > > In 1.x terms, the 1.3. release is running near the average. > We're in the 17th month, and 1.x releases have been averaging > 18. (Struts 1.1 took two years.) And, in the meantime, we've > had significant 1.2 milestone releases too. Given that 1.2.9 > when GA in March 2006, from last GA to first GA, 1.3 is > liable to be our quickest release yet. :) > > Still, for 2.x and beyond, I'd like to do better. I didn't mean to nag or sound negative, but I'm glad you plan to do better. It isn't really the time between new features and bug fixes that "bother me" much, it's the time they take to finalize and release. The latest 1.3 releases have, to my recollection, had pretty few issues that have prevented them from being GA. Then it takes several months before you give it another try. I understand you all have limited time and resources, but when the code has been as stable and complete for so long as is the case with 1.3, I don't see why you (as in "the Struts commiters", not you particularly Ted ;) can't push it through faster. Couldn't some 2.0 work halted to just get this done? Again, I only mean this as constructive criticism, as I wish for Struts 2.x the very best. :) This is, I guess, pretty much what Ted and Don are talking about regarding 2.0.0. Please concentrate on the nearest release (which will hopefully be 2.0.0 very soon) instead of scattering your resources all over the place. :) \Anders - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [s2] Struts 2.0.0 - Tag it and Roll it?
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Ted Husted > Sent: 24. juli 2006 21:53 > To: Struts Developers List > Subject: Re: [s2] Struts 2.0.0 - Tag it and Roll it? > > -1 on changing the versioning scheme. > > But, I would be open to something like > > * Struts 2.0 == "WebWork transtional release" > * Struts 2.1 == "new API release" > * Struts 3.x == "phase 2 - the best of breed release" > > IMHO, all the users, including ourselves, are served best > when we release early and release often. Isn't this kind of ironic you repeating this over and over again given the state of the 1.3 release? (Yes, I know a vote is pending, but it sure has taken a heck of a long time.) \Anders - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts JIRA Roadmap
> -Original Message- > From: Wendy Smoak [mailto:[EMAIL PROTECTED] > Sent: 30. juni 2006 22:31 > To: Struts Developers List > Subject: Re: Struts JIRA Roadmap > > On 6/30/06, Paul Benedict <[EMAIL PROTECTED]> wrote: > > > I should have seen the next 3 versions thing. I guess my > question was because I was looking for the next 3 versions -- > hoping 1.3.5 would be there. Any idea why that's not within the 3? > > My guess is that it has something to do with Manage Versions > -> Release. Maybe we need to "release" all the old versions > to get them off the roadmap? Someone who has worked more > with JIRA can probably advise. Yes, that is the place to fix this. Releasing versions will remove them from the roadmap, but you should probably archive some of them as well (i.e. 0.5), which will make them unavailible for selections in versions drop-down lists. (0.5 should be irrelevant by now ;) \Anders - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts Shale
> -Original Message- > From: Craig McClanahan [mailto:[EMAIL PROTECTED] > On Fri, 29 Oct 2004 01:22:09 +0200, Anders Steinlein > <[EMAIL PROTECTED]> wrote: > > > > Although I have no real saying in this, I am +1 on J2SE 5.0 > > as well. As I would anticipate 1-2 years in development on > > Struts 2.x, J2SE 5.0 should be widely deployed by then. If > > not, then our "endorsement" of it could encourage people to > > make the switch. ;) Plus, it could stand as a marketing bonus > > - in support of our "revolutionary" path. > > I sure hope it doesn't take us 1-2 years, but with our track > record I'd be pretty foolish to make any promises at this point :-). I sure doesn't hope so either. Besides, I suspect more people would like to volunteer on a 2.x release to scratch some revolutionary itches and/or understanding the framework from the beginning (myself included), which could help speed things up. :) > > Quick questions regarding Commons Logging proposal: > > > > Letting people choose their logging implementation is not a > > bad idea, but I've been hearing negative things about Commons > > Logging in its ability to detect the correct implementation > > to use. Something about classpath problems, if I remember > > correctly? Are these issues solved? > > 99.9% of the issue is configuration -- getting the right JARs > and configuration files in the right place. In that sense > its not really different than any other JAR that might be > included in the webapp or installed in the container. You > just need to get all the moving parts where they belong. And > use C-L 1.0.4 or later, of course, because there were some > critical bugfixes. Ah, that explains it. Thanks for clearing this up for me. > Struts 1.x has used C-L from the very beginning of its > existence, and we've been satisfied with it. > > > Again, this is > > just little me's two cents, but I am in favor of minimizing third > > party dependencies as much as possible, and I don't see very much > > reason not to use the JDK 1.4 implementation. Anyone? > > There are a lot of potential customers that have existing > environments based on things like Log4J, and those folks > would be really (and justifiably) irritated to be required > to configure two logging systems. Indeed good and valid points - I'm sold. > Craig \Anders - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts Shale
> -Original Message- > From: Craig McClanahan [mailto:[EMAIL PROTECTED] > On Fri, 29 Oct 2004 01:22:09 +0200, Anders Steinlein > <[EMAIL PROTECTED]> wrote: > > > > Although I have no real saying in this, I am +1 on J2SE 5.0 > > as well. As I would anticipate 1-2 years in development on > > Struts 2.x, J2SE 5.0 should be widely deployed by then. If > > not, then our "endorsement" of it could encourage people to > > make the switch. ;) Plus, it could stand as a marketing bonus > > - in support of our "revolutionary" path. > > I sure hope it doesn't take us 1-2 years, but with our track > record I'd be pretty foolish to make any promises at this point :-). I sure doesn't hope so either. Besides, I suspect more people would like to volunteer on a 2.x release to scratch some revolutionary itches and/or understanding the framework from the beginning (myself included), which could help speed things up. :) > > Quick questions regarding Commons Logging proposal: > > > > Letting people choose their logging implementation is not a > > bad idea, but I've been hearing negative things about Commons > > Logging in its ability to detect the correct implementation > > to use. Something about classpath problems, if I remember > > correctly? Are these issues solved? > > 99.9% of the issue is configuration -- getting the right JARs > and configuration files in the right place. In that sense > its not really different than any other JAR that might be > included in the webapp or installed in the container. You > just need to get all the moving parts where they belong. And > use C-L 1.0.4 or later, of course, because there were some > critical bugfixes. Ah, that explains it. Thanks for clearing this up for me. > Struts 1.x has used C-L from the very beginning of its > existence, and we've been satisfied with it. > > > Again, this is > > just little me's two cents, but I am in favor of minimizing third > > party dependencies as much as possible, and I don't see very much > > reason not to use the JDK 1.4 implementation. Anyone? > > There are a lot of potential customers that have existing > environments based on things like Log4J, and those folks > would be really (and justifiably) irritated to be required > to configure two logging systems. Indeed good and valid points - I'm sold. > Craig \Anders - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts Shale
> > > 3.1 Java2 Standard Edition APIs > > I'd be +1 for J2SE 5.0 Although I have no real saying in this, I am +1 on J2SE 5.0 as well. As I would anticipate 1-2 years in development on Struts 2.x, J2SE 5.0 should be widely deployed by then. If not, then our "endorsement" of it could encourage people to make the switch. ;) Plus, it could stand as a marketing bonus - in support of our "revolutionary" path. Quick questions regarding Commons Logging proposal: Letting people choose their logging implementation is not a bad idea, but I've been hearing negative things about Commons Logging in its ability to detect the correct implementation to use. Something about classpath problems, if I remember correctly? Are these issues solved? Again, this is just little me's two cents, but I am in favor of minimizing third party dependencies as much as possible, and I don't see very much reason not to use the JDK 1.4 implementation. Anyone? Regards, \Anders - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts Shale
> > > 3.1 Java2 Standard Edition APIs > > I'd be +1 for J2SE 5.0 Although I have no real saying in this, I am +1 on J2SE 5.0 as well. As I would anticipate 1-2 years in development on Struts 2.x, J2SE 5.0 should be widely deployed by then. If not, then our "endorsement" of it could encourage people to make the switch. ;) Plus, it could stand as a marketing bonus - in support of our "revolutionary" path. Quick questions regarding Commons Logging proposal: Letting people choose their logging implementation is not a bad idea, but I've been hearing negative things about Commons Logging in its ability to detect the correct implementation to use. Something about classpath problems, if I remember correctly? Are these issues solved? Again, this is just little me's two cents, but I am in favor of minimizing third party dependencies as much as possible, and I don't see very much reason not to use the JDK 1.4 implementation. Anyone? Regards, \Anders - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts Shale
I have to agree with Craig here. Although I haven't used JSF that much yet, I have investigated it enough to understand its basic infrastructure and functionality. As Craig said, it would require much work to abstract the same functionality in to Struts, where it is already available in JSF (such as view navigation). One of my personal wishes for Struts 2.x (and I would love to volunteer) is a smooth and clear integration with JSF. Many people are confused about how JSF fits in with frameworks such as Struts (and webapps in general), and this would be a great opportunity to clear that up once and for all. Besides, it would put us in a good position marketing-wise, as there aren't currently any frameworks (to mine knowledge anyway) utilizing JSF in this manner. Shale should then focus on adding neat features "outside" of what JSF already does. I do wonder about one thing though - how would portlets fit into all this? I know next to nothing about portlets, except that I feel it should be supported out-of-the-box in Struts 2.x. Could JSF be used in that regard? Regards, \Anders > -Original Message- > From: Craig McClanahan [mailto:[EMAIL PROTECTED] > Sent: 28. oktober 2004 19:40 > To: Dakota Jack; Struts Developers List > Subject: Re: Struts Shale > > I think that's Ted's basic point. > > My answer is to consider how much extra machinery you have to > build in to the Struts abstraction of what a ViewController > is so that an application built on top of Struts can use > different technologies. > > Just as one example out of my list from the previous email > ... how does a ViewController say "I want to switch to a new > view"? With JSF that's easy ... support for navigation is > built in based on the string value that's returned by your > action mapping, which is processed through the navigation > rules that you've defined in faces-config.xml to pick the > next view. Without JSF, someone is going to have to build in > a way for a ViewController to ask for that -- and that's > redundant work. > > Part of the potential confusion here is based on the fact > that JSF isn't just a dynamic rendering technology. Indeed, > JSF itself is agnostic whether you want to use JSP pages or > Velocity (although you'll need to provide your own > ViewHandler plugin for the latter case, but it's not tough to > write one). The key difference is that JSF already has a > well defined request processing lifecycle built in, following > the Front Controller design pattern in a manner fairly > similar to the way that Struts currently works. I want to > leverage that instead of abstracting it out or reinventing it > -- JSF's already good enough. > > Craig > > On Thu, 28 Oct 2004 10:23:37 -0700, Dakota Jack > <[EMAIL PROTECTED]> wrote: > > Why is it not possible for the framework to use interfaces > into which > > JSF can be plugged in, perhaps with adapters, as an option well as > > other alternatives? This too is not a rhetorical question. > > > > Jack - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts Shale
I have to agree with Craig here. Although I haven't used JSF that much yet, I have investigated it enough to understand its basic infrastructure and functionality. As Craig said, it would require much work to abstract the same functionality in to Struts, where it is already available in JSF (such as view navigation). One of my personal wishes for Struts 2.x (and I would love to volunteer) is a smooth and clear integration with JSF. Many people are confused about how JSF fits in with frameworks such as Struts (and webapps in general), and this would be a great opportunity to clear that up once and for all. Besides, it would put us in a good position marketing-wise, as there aren't currently any frameworks (to mine knowledge anyway) utilizing JSF in this manner. Shale should then focus on adding neat features "outside" of what JSF already does. I do wonder about one thing though - how would portlets fit into all this? I know next to nothing about portlets, except that I feel it should be supported out-of-the-box in Struts 2.x. Could JSF be used in that regard? Regards, \Anders > -Original Message- > From: Craig McClanahan [mailto:[EMAIL PROTECTED] > Sent: 28. oktober 2004 19:40 > To: Dakota Jack; Struts Developers List > Subject: Re: Struts Shale > > I think that's Ted's basic point. > > My answer is to consider how much extra machinery you have to > build in to the Struts abstraction of what a ViewController > is so that an application built on top of Struts can use > different technologies. > > Just as one example out of my list from the previous email > ... how does a ViewController say "I want to switch to a new > view"? With JSF that's easy ... support for navigation is > built in based on the string value that's returned by your > action mapping, which is processed through the navigation > rules that you've defined in faces-config.xml to pick the > next view. Without JSF, someone is going to have to build in > a way for a ViewController to ask for that -- and that's > redundant work. > > Part of the potential confusion here is based on the fact > that JSF isn't just a dynamic rendering technology. Indeed, > JSF itself is agnostic whether you want to use JSP pages or > Velocity (although you'll need to provide your own > ViewHandler plugin for the latter case, but it's not tough to > write one). The key difference is that JSF already has a > well defined request processing lifecycle built in, following > the Front Controller design pattern in a manner fairly > similar to the way that Struts currently works. I want to > leverage that instead of abstracting it out or reinventing it > -- JSF's already good enough. > > Craig > > On Thu, 28 Oct 2004 10:23:37 -0700, Dakota Jack > <[EMAIL PROTECTED]> wrote: > > Why is it not possible for the framework to use interfaces > into which > > JSF can be plugged in, perhaps with adapters, as an option well as > > other alternatives? This too is not a rhetorical question. > > > > Jack - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: CVS -> SVN
Forgive my possible ignorance, but what is the policy on new releases? I've understood that we can release whenever we want, that version numbers are cheap and that you vote whether to make a release alpha/beta/GA. But, what goes into a release? Does new features/enhancements go into a 1.2.x release, or is it strictly bug fixes? The reason I ask is because I would love releases much, much more often, but as have been pointed out, incompatibilities/quirks between minor versions could be a disaster. \Anders > -Original Message- > From: James Mitchell [mailto:[EMAIL PROTECTED] > Sent: 13. oktober 2004 15:38 > To: Struts Developers List > Subject: Re: CVS -> SVN > > I'd like to roll a release after you are finished with that. > I really, REALLY want to keep these rolling (about 1 every > few weeks) which has the added benefit of (hopefully) > breaking this bad habit we seem to be in (~18 month GA release cycle). > > > -- > James Mitchell > Software Engineer / Open Source Evangelist EdgeTech, Inc. > 678.910.8017 > AIM: jmitchtx - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: CVS -> SVN
Forgive my possible ignorance, but what is the policy on new releases? I've understood that we can release whenever we want, that version numbers are cheap and that you vote whether to make a release alpha/beta/GA. But, what goes into a release? Does new features/enhancements go into a 1.2.x release, or is it strictly bug fixes? The reason I ask is because I would love releases much, much more often, but as have been pointed out, incompatibilities/quirks between minor versions could be a disaster. \Anders > -Original Message- > From: James Mitchell [mailto:[EMAIL PROTECTED] > Sent: 13. oktober 2004 15:38 > To: Struts Developers List > Subject: Re: CVS -> SVN > > I'd like to roll a release after you are finished with that. > I really, REALLY want to keep these rolling (about 1 every > few weeks) which has the added benefit of (hopefully) > breaking this bad habit we seem to be in (~18 month GA release cycle). > > > -- > James Mitchell > Software Engineer / Open Source Evangelist EdgeTech, Inc. > 678.910.8017 > AIM: jmitchtx - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Roadmap
> -Original Message- > From: Ted Husted [mailto:[EMAIL PROTECTED] > Sent: 13. oktober 2004 16:13 > To: Struts Developers List > Subject: RE: Roadmap > > On Wed, 13 Oct 2004 12:53:10 +0100, Pilgrim, Peter wrote: > > I think we need to define a feature common denominator table of > > what constitutes a request and response as we know they exist now. > > I'm of like mind, but I'd like to take a step farther back > and define a set of Struts use case scenarios, for both this > generation and the next. > > > (0) Client submits request > > (1) System receives the incoming request > > (2) System transfers matching values to a form object > > (3) System > > validates the object > > (4) System branches to success or failure. > > (4a) On success, system executes/delegates the business logic. > > (4b) On failure, system returns the faulty input. > > (5) A view displays the nominal result or redisplays faulty input. > > And so on. > > Then we'd have a clear idea of what we are building the > interfaces to do. I agree on the need to define use case scenarios. I for one would like to "fix" the Struts/JSF confusion, and maybe integrate and promote Struts-Faces or a similar implementation, much like we are promoting the use of JSTL-tags instead of the bean/logic taglibs. This, of course, doesn't rule out next generation web apps and special request/resonse types, but we should IMO first and foremost define how much of an evolution or revolution we want. \Anders - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Roadmap
> -Original Message- > From: Ted Husted [mailto:[EMAIL PROTECTED] > Sent: 13. oktober 2004 16:13 > To: Struts Developers List > Subject: RE: Roadmap > > On Wed, 13 Oct 2004 12:53:10 +0100, Pilgrim, Peter wrote: > > I think we need to define a feature common denominator table of > > what constitutes a request and response as we know they exist now. > > I'm of like mind, but I'd like to take a step farther back > and define a set of Struts use case scenarios, for both this > generation and the next. > > > (0) Client submits request > > (1) System receives the incoming request > > (2) System transfers matching values to a form object > > (3) System > > validates the object > > (4) System branches to success or failure. > > (4a) On success, system executes/delegates the business logic. > > (4b) On failure, system returns the faulty input. > > (5) A view displays the nominal result or redisplays faulty input. > > And so on. > > Then we'd have a clear idea of what we are building the > interfaces to do. I agree on the need to define use case scenarios. I for one would like to "fix" the Struts/JSF confusion, and maybe integrate and promote Struts-Faces or a similar implementation, much like we are promoting the use of JSTL-tags instead of the bean/logic taglibs. This, of course, doesn't rule out next generation web apps and special request/resonse types, but we should IMO first and foremost define how much of an evolution or revolution we want. \Anders - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Jericho Whiteboard (was RE: [VOTE] Move minimum to 2.3 )
> On Fri, 03 Sep 2004 19:29:51 +0200, Anders Steinlein wrote: > >Wow, didn't know about that one - quite interesting. What > >about pushing > >it out to the wiki? I can probably do it (and learn some > >wiki stuff) if Ted or anyone else doesn't mind. > > That would be fine, Anders. Thanks for volunteering! :) > > -Ted. Done! Quite fun stuff, the Wiki. I might actually be making more use of it. ;) \Anders - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Jericho Whiteboard (was RE: [VOTE] Move minimum to 2.3 )
> On Fri, 03 Sep 2004 19:29:51 +0200, Anders Steinlein wrote: > >Wow, didn't know about that one - quite interesting. What > >about pushing > >it out to the wiki? I can probably do it (and learn some > >wiki stuff) if Ted or anyone else doesn't mind. > > That would be fine, Anders. Thanks for volunteering! :) > > -Ted. Done! Quite fun stuff, the Wiki. I might actually be making more use of it. ;) \Anders - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Move minimum to 2.3 (was Re: Changing how CommonsMultipartRequestHandler handles text parameters?)
Wow, didn't know about that one - quite interesting. What about pushing it out to the wiki? I can probably do it (and learn some wiki stuff) if Ted or anyone else doesn't mind. \Anders > -Original Message- > From: James Mitchell [mailto:[EMAIL PROTECTED] > Sent: 2. september 2004 21:33 > To: Struts Developers List > Subject: Re: [VOTE] Move minimum to 2.3 (was Re: Changing how > CommonsMultipartRequestHandler handles text parameters?) > > You can also look at the whiteboard initially setup by Ted in > contrib/struts-jericho/README.txt > > > > -- > James Mitchell > Software Engineer / Open Source Evangelist EdgeTech, Inc. > 678.910.8017 > AIM: jmitchtx > > - Original Message - > From: "Niall Pemberton" <[EMAIL PROTECTED]> > To: "Struts Developers List" <[EMAIL PROTECTED]> > Sent: Thursday, September 02, 2004 3:33 PM > Subject: Re: [VOTE] Move minimum to 2.3 (was Re: Changing how > CommonsMultipartRequestHandler handles text parameters?) > > > > Maybe the "whiteboard" area is good fot this... > > > > http://wiki.apache.org/struts/StrutsWhiteboard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Move minimum to 2.3 (was Re: Changing how CommonsMultipartRequestHandler handles text parameters?)
Wow, didn't know about that one - quite interesting. What about pushing it out to the wiki? I can probably do it (and learn some wiki stuff) if Ted or anyone else doesn't mind. \Anders > -Original Message- > From: James Mitchell [mailto:[EMAIL PROTECTED] > Sent: 2. september 2004 21:33 > To: Struts Developers List > Subject: Re: [VOTE] Move minimum to 2.3 (was Re: Changing how > CommonsMultipartRequestHandler handles text parameters?) > > You can also look at the whiteboard initially setup by Ted in > contrib/struts-jericho/README.txt > > > > -- > James Mitchell > Software Engineer / Open Source Evangelist EdgeTech, Inc. > 678.910.8017 > AIM: jmitchtx > > - Original Message - > From: "Niall Pemberton" <[EMAIL PROTECTED]> > To: "Struts Developers List" <[EMAIL PROTECTED]> > Sent: Thursday, September 02, 2004 3:33 PM > Subject: Re: [VOTE] Move minimum to 2.3 (was Re: Changing how > CommonsMultipartRequestHandler handles text parameters?) > > > > Maybe the "whiteboard" area is good fot this... > > > > http://wiki.apache.org/struts/StrutsWhiteboard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Move minimum to 2.3 (was Re: Changing how CommonsMultipartRequestHandler handles text parameters?)
> > It's more than a thought ... I was about three keystrokes from > > including this in my proposal to be forward looking on > servlet 2.4 and > > JSP 2.0 :-). > > > > I'd love to see Servlet2.4 and JSP2.0 be the minimum. > > It was mentioned before that several of the 'itches' that the > committers have revolve around more recent versions of the > specs. I would think that this logic could also be applied > to potential contributors who have been sitting on the > sidelines waiting to figure out how to get involved. > > Newer technoloy yeilds new ideas and new contributions. Just want to throw in my voice here, as this is exactly what I've been thinking. I'm very pleased with Struts and use it on a daily basis and I would love to contribute, but I don't really have the itches or time to fully read up on the current code. However, upon the development of a "revolution"-Struts, I and surely many others would be inspired to get involved right from the start. Just the thought of a Struts fully based on Servlet 2.4, JSP 2.0 and possibly even J2SE 5.0 makes me all warm inside. ;) \Anders - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Move minimum to 2.3 (was Re: Changing how CommonsMultipartRequestHandler handles text parameters?)
> > It's more than a thought ... I was about three keystrokes from > > including this in my proposal to be forward looking on > servlet 2.4 and > > JSP 2.0 :-). > > > > I'd love to see Servlet2.4 and JSP2.0 be the minimum. > > It was mentioned before that several of the 'itches' that the > committers have revolve around more recent versions of the > specs. I would think that this logic could also be applied > to potential contributors who have been sitting on the > sidelines waiting to figure out how to get involved. > > Newer technoloy yeilds new ideas and new contributions. Just want to throw in my voice here, as this is exactly what I've been thinking. I'm very pleased with Struts and use it on a daily basis and I would love to contribute, but I don't really have the itches or time to fully read up on the current code. However, upon the development of a "revolution"-Struts, I and surely many others would be inspired to get involved right from the start. Just the thought of a Struts fully based on Servlet 2.4, JSP 2.0 and possibly even J2SE 5.0 makes me all warm inside. ;) \Anders - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
