Struts 1.3.1 - When?

Now that 1.2 is EOL (end of line), what's the timeframe for the 1.3.1 release? I ask this because now that so many people are dedicated to 2.0, I am a bit concerned this product might drop out of people's sight. -- Paul __ Do You Yahoo!? Tired of spa

svn commit: r388871 - in /struts/sandbox/trunk/action2: ./ apps/mailreader/src/java/ apps/mailreader/src/java/mailreader2/ apps/mailreader/src/webapp/pages/

Author: husted Date: Sat Mar 25 18:54:18 2006 New Revision: 388871 URL: http://svn.apache.org/viewcvs?rev=388871&view=rev Log: Action2 Apps * Mailreader - Work in progress ** Add validation for Subscription. Added: struts/sandbox/trunk/action2/STATUS.txt (with props) struts/sandbox/tr

svn commit: r388869 - in /struts/sandbox/trunk/action2: ./ apps/mailreader/src/java/ apps/mailreader/src/java/mailreader2/ apps/mailreader/src/webapp/WEB-INF/ apps/mailreader/src/webapp/pages/

Author: husted Date: Sat Mar 25 18:17:14 2006 New Revision: 388869 URL: http://svn.apache.org/viewcvs?rev=388869&view=rev Log: Action2 Apps * Mailreader - Work in progress ** JavaDoc pass Modified: struts/sandbox/trunk/action2/README.txt struts/sandbox/trunk/action2/apps/mailreader/src/

Re: WebWork renaming strategy *revised*

On 3/25/06, Joe Germuska <[EMAIL PROTECTED]> wrote: > I think there's something here. Certainly, Gabe articulates my > dissatisfaction with action2 -- it is possible to imagine a > revolution from Struts 2 to Struts 3 which does not require > completely reorganizing the package structure, but if t

Re: WebWork renaming strategy *revised*

> I think there's something here. Certainly, Gabe articulates my > dissatisfaction with action2 -- it is possible to imagine a > revolution from Struts 2 to Struts 3 which does not require > completely reorganizing the package structure, but if there's an > "action2" package lying around, that

Re: WebWork renaming strategy *revised*

The reasoning behind this is: 1) action2/ti is really just another version so shouldn't be given a package name based on the version (when we go version 3 code named something else will we have to change the package names again?). Thus, it should stay at org.apache.struts. 2) Webwork as discuss

svn commit: r388862 - in /struts/sandbox/trunk/action2: ./ apps/mailreader/src/webapp/pages/

Author: husted Date: Sat Mar 25 16:18:26 2006 New Revision: 388862 URL: http://svn.apache.org/viewcvs?rev=388862&view=rev Log: Action2 Apps * Mailreader - Work in progress ** Standardize on "saf" for now. Modified: struts/sandbox/trunk/action2/README.txt struts/sandbox/trunk/action2/ap

Re: WebWork renaming strategy *revised*

Agreed. However, putting webwork in the web subpackage takes care of this issue, no? Also, if 3.0 were an evolution rather than a revolution, then what would the meaning behind having Action 3.0 classes under the action2 package? - Original Message From: Paul Benedict <[EMAIL PROTECTE

Re: WebWork renaming strategy *revised*

Gabe, the best argument, I see, behind an "action2" package is that it's totally incompatible with the previous version. You wouldn't want to mix action1 and action2 classes in the same namespace. You only would want to separate packages between Action 3.0 and 2.0 if 3.0 was another revolution, not

Re: WebWork renaming strategy *revised*

I'll propose something a little out of left field: - com.opensymphony.webwork package -> org.apache.struts.web - WebWork* classes -> Web* - WebWork in comments, documentation -> Struts - webwork. as the configuration properties prefix -> struts. - ww: tag prefix -> web: The reasoning behind

svn commit: r388856 - in /struts/sandbox/trunk/action2: ./ apps/mailreader/src/java/ apps/mailreader/src/java/mailreader2/ apps/mailreader/src/webapp/pages/

Author: husted Date: Sat Mar 25 15:16:07 2006 New Revision: 388856 URL: http://svn.apache.org/viewcvs?rev=388856&view=rev Log: Action2 Apps * Mailreader - Work in progress ** Complete critical path ** Still issues to resolve, but the core logic and workflow are in. Modified: struts/sandbox/

Re: WebWork renaming strategy *revised*

On 3/25/06, Don Brown <[EMAIL PROTECTED]> wrote: > > I'm in favor of either, and in fact, I've already repackaged the code > under org.apache.struts.action2, so if I had to pick, I'd pick the one > that doesn't have me duplicating work :) Me too (in favor of either), but the fact that several dev

Re: WebWork renaming strategy *revised*

On 3/25/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote: > +1 ("saf" as default tag prefix). On the other hand, would be nice to > have a taglib that can be used without Struts whenever possible. > Therefore, "af" ;-) The UI tags are the definately the "cat's meow". It would be nifty if we could

Re: WebWork renaming strategy *revised*

On 3/25/06, Ted Husted <[EMAIL PROTECTED]> wrote: > - com.opensymphony.webwork package -> org.apache.struts.action2 > - WebWork* classes -> Struts* > - WebWork in comments, documentation -> Struts Action 2 > - webwork. as the configuration properties prefix -> struts. > - ww: tag prefix -> a:/

Re: WebWork renaming strategy *revised*

I'm in favor of either, and in fact, I've already repackaged the code under org.apache.struts.action2, so if I had to pick, I'd pick the one that doesn't have me duplicating work :) Don Ted Husted wrote: STATUS so far - com.opensymphony.webwork package -> org.apache.struts.ti - WebWork* cl

Re: WebWork renaming strategy *revised*

STATUS so far - com.opensymphony.webwork package -> org.apache.struts.ti - WebWork* classes -> Struts* - WebWork in comments, documentation -> Struts Action 2 - webwork. as the configuration properties prefix -> struts. - ww: tag prefix -> a: +1 Don Brown, Martin Cooper (binding) +1 Frank Za

Re: [Struts Ti] XWork?

On 3/25/06, Gabe <[EMAIL PROTECTED]> wrote: > I'm sure I could come up with more reasons, but this is a good start to this > discussion. I don't think anyone would have a problem with this, Gabe. It's just a matter of whether we need to bring XWork and WebWork through simultaneously, or whether w

DO NOT REPLY [Bug 39040] - Refactor Struts initialization to ServletContextListener

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

[Struts Ti] XWork?

Hi! I don't think I have posted to this list yet. I am Gabe, XWork/Webwork developer. Now that I see that discussions are starting about the merger I wanted to bring up an issue that I brought up on the WW boards that was tabled for just this moment (or after incubation?) The issue is whether

Re: taglib cactus

On 3/25/06, Wendy Smoak <[EMAIL PROTECTED]> wrote: > On 3/25/06, Mark Lowe <[EMAIL PROTECTED]> wrote: > > > I've been running the cactus tests for the tag lib and a get a lot of > > errors. I'm not bitching I just want to know what the current state of > > play is with the taglibs, and what is expe

svn commit: r388808 - in /struts/sandbox/trunk/action2/apps/mailreader/src: java/mailreader2/MailreaderSupport.java java/mailreader2/Subscription.java java/xwork.xml webapp/pages/Registration.jsp weba

Author: husted Date: Sat Mar 25 12:01:20 2006 New Revision: 388808 URL: http://svn.apache.org/viewcvs?rev=388808&view=rev Log: Action2 Apps * Mailreader ** xwork - Change result-types from chain to result-action, per exchange with Toby on WW Dev. ** Registration - Turn off client-side validation

Re: taglib cactus

On 3/25/06, Mark Lowe <[EMAIL PROTECTED]> wrote: > I've been running the cactus tests for the tag lib and a get a lot of > errors. I'm not bitching I just want to know what the current state of > play is with the taglibs, and what is expected in terms of test > results? > > If anyone can get me up

Re: odd pecularity in source difference for JavascriptValidatorTag.java between 1.2.8 and 1.2.9

No, it just wasn't back ported to the 1.2.x branch. Bug 38081 wasn't (IMO) that serious anyway, since the consequences are only some addtional warnings in the logs in certain circumstances. Niall On 3/24/06, Haroon Rafique <[EMAIL PROTECTED]> wrote: > Hi there, > > Please let me know if this is a

Re: WebWork renaming strategy *revised*

Paul Benedict wrote: Johnathan, I don't see the necessity of a problem from within your viewpoint. Struts 2.0 is going to be built from WebWork; I suppose you can consider Struts 2.0 a fork of WebWork, Well, it's not _really_ a fork. The main Webwork developers are coming over here. But i

Re: WebWork renaming strategy *revised*

Ted Husted wrote: On 3/25/06, Paul Benedict <[EMAIL PROTECTED]> wrote: Isn't the purpose of this to excise the webwork name? I thought it was. Why else would you want to become "Struts 2.0" if not for the name? I don't see this renaming as a slam against the heritage, but this entire process do

Re: WebWork renaming strategy *revised*

Johnathan, I don't see the necessity of a problem from within your viewpoint. Struts 2.0 is going to be built from WebWork; I suppose you can consider Struts 2.0 a fork of WebWork, because, unless I am unaware of something here, this doesn't prevent other people from developing WebWork if they wa

Re: WebWork and LGPL dependencies

On 3/25/06, Rainer Hermanns <[EMAIL PROTECTED]> wrote: > > Some of the LGPL dependencies were already moved out of the main > build process. > As far as I could see the hibernate dep can completely be removed, > cause there is no hibernate > specific code in the codebase, just within the wikidocs.

Re: WebWork renaming strategy *revised*

On 3/24/06, Don Brown <[EMAIL PROTECTED]> wrote: > > Ok, after listening to all the feedback, here is my revised renaming > strategy proposal: > > - com.opensymphony.webwork package -> org.apache.struts.ti > - WebWork* classes -> Struts* > - WebWork in comments, documentation -> Struts Action 2 > -

Re: WebWork renaming strategy *revised*

On 3/25/06, Paul Benedict <[EMAIL PROTECTED]> wrote: > Isn't the purpose of this to excise the webwork name? I thought > it was. Why else would you want to become "Struts 2.0" if not > for the name? I don't see this renaming as a slam against the heritage, > but this entire process doesn't make any

Re: WebWork renaming strategy *revised*

Paul Benedict wrote: cry that they are so innocent and all (such wonderful people) but surely there is some agenda in wanting to excise "webwork" and "ww" from all the code, isn't there? Isn't the purpose of this to excise the webwork name? Well, at the marketing level, maybe. That this ne

Re: WebWork renaming strategy *revised*

>>cry that they are so innocent and all (such wonderful >>people) but surely there is some agenda in wanting to excise "webwork" >>and "ww" from all the code, isn't there? Isn't the purpose of this to excise the webwork name? I thought it was. Why else would you want to become "Struts 2.0" if no

Re: WebWork renaming strategy *revised*

Hubert Rabago wrote: On 3/24/06, Ted Husted <[EMAIL PROTECTED]> wrote: I don't see the problem with Action2 either. Hopefully, we will someday see an Action3 and Action4 too. But, regardless of what I think, I would suggest that we wait a few days and give the other new committers a chance to

taglib cactus

Hello I've been running the cactus tests for the tag lib and a get a lot of errors. I'm not bitching I just want to know what the current state of play is with the taglibs, and what is expected in terms of test results? If anyone can get me up to speed I'd appeciate it. Mark ---

Re: WebWork renaming strategy *revised*

On 3/25/06, Ed Griebel <[EMAIL PROTECTED]> wrote: > Good point about to type and is pretty specific. > > Also, the tinyurl link doesn't work. Here's the long one * http://svn.apache.org/viewcvs.cgi/struts/sandbox/trunk/action2/apps/mailreader/src/webapp/pages/ And another try at a tiny one * h

svn commit: r388772 - /struts/sandbox/trunk/action2/apps/mailreader/src/webapp/pages/ChangePassword.jsp

Author: husted Date: Sat Mar 25 07:22:16 2006 New Revision: 388772 URL: http://svn.apache.org/viewcvs?rev=388772&view=rev Log: Action2 Apps * Mailreader - Try some different tag prefixes on for size. Modified: struts/sandbox/trunk/action2/apps/mailreader/src/webapp/pages/ChangePasswo

Re: WebWork renaming strategy *revised*

Good point about wrote: > On 3/25/06, Rene Gielen <[EMAIL PROTECTED]> wrote: > > So I am > > +1 for the package name 'org.apache.struts.action2' > > +1 for tag prefix a > > +1 for the other points of Don's proposal > > Of course, the tag prefix is something configured on a page-by-page > basis. In

Re: Struts Shale v1.0.2 Quality

+1 (non binding) for Alpha On 3/23/06, Gary VanMatre <[EMAIL PROTECTED]> wrote: > +1 for Alpha as well. Outside of the one known issue with the sql-browser > application, it looks good. Nice work Wendy. > > Gary > > -- Original message -- > From: "Wendy Smoak" <[EMAIL PRO

svn commit: r388754 - /struts/shale/trunk/use-cases/src/web/WEB-INF/clay-config.xml

Author: gvanmatre Date: Sat Mar 25 05:29:45 2006 New Revision: 388754 URL: http://svn.apache.org/viewcvs?rev=388754&view=rev Log: Fixed a bogus attribute that was reported by Hermod Opstvedt Modified: struts/shale/trunk/use-cases/src/web/WEB-INF/clay-config.xml Modified: struts/shale/trunk/

Re: WebWork and LGPL dependencies

On 3/25/06, Rainer Hermanns <[EMAIL PROTECTED]> wrote: > How should those be "refactored"? Is there a guideline available for > removing the "bad" deps? First, we should contact the authors and make sure they do want to put the code under the LGPL. Sometimes people use that as a default and don't

svn commit: r388749 - /struts/shale/trunk/use-cases/src/java/org/apache/shale/usecases/rolodex/Rolodex.java

Author: gvanmatre Date: Sat Mar 25 05:11:02 2006 New Revision: 388749 URL: http://svn.apache.org/viewcvs?rev=388749&view=rev Log: Code clarification suggested by Hermod Opstvedt Modified: struts/shale/trunk/use-cases/src/java/org/apache/shale/usecases/rolodex/Rolodex.java Modified: struts

Re: WebWork renaming strategy *revised*

On 3/25/06, Rene Gielen <[EMAIL PROTECTED]> wrote: > So I am > +1 for the package name 'org.apache.struts.action2' > +1 for tag prefix a > +1 for the other points of Don's proposal Of course, the tag prefix is something configured on a page-by-page basis. In my own work, I might find "a" difficult

svn commit: r388746 - in /struts/sandbox/trunk/action2/apps/mailreader/src/webapp/pages: MainMenu.jsp Registration.jsp Subscription.jsp Welcome.jsp

Author: husted Date: Sat Mar 25 04:45:08 2006 New Revision: 388746 URL: http://svn.apache.org/viewcvs?rev=388746&view=rev Log: Action2 Apps * Mailreader - Try some different tag prefixes on for size. Modified: struts/sandbox/trunk/action2/apps/mailreader/src/webapp/pages/MainMenu.jsp

Re: WebWork renaming strategy *revised*

On 3/24/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote: > So, "Struts", "Struts Action 2", "ti" and "a" instead of "WebWork", > "WebWork", "webwork" and "ww". New name system is definetely an > improvent consistency-wise. :) "a:" was my suggestion. It'd only make sense paired with "Action 2" and

Re: WebWork renaming strategy *revised*

On 3/24/06, Ted Husted <[EMAIL PROTECTED]> wrote: > I don't see the problem with Action2 either. Hopefully, we will > someday see an Action3 and Action4 too. > > But, regardless of what I think, I would suggest that we wait a few > days and give the other new committers a chance to chime in. Ian >

Re: WebWork renaming strategy *revised*

Hi Guys, I'd follow any naming strategy that the community has agreed upon. Rene Gielen <[EMAIL PROTECTED]> wrote: Don, see below: Don Brown schrieb: > Ok, after listening to all the feedback, here is my revised renaming > strategy proposal: > > - com.opensymphony.webwork package -> org.ap

Re: WebWork renaming strategy *revised*

Don, see below: Don Brown schrieb: > Ok, after listening to all the feedback, here is my revised renaming > strategy proposal: > > - com.opensymphony.webwork package -> org.apache.struts.ti > - WebWork* classes -> Struts* > - WebWork in comments, documentation -> Struts Action 2 > - webwork. as

Re: WebWork renaming strategy *revised*

IMO we should keep the names as consistent as possible so my vote would go for: - com.opensymphony.webwork package -> org.apache.struts.action2 - WebWork* classes -> Struts* - WebWork in comments, documentation -> Struts Action 2 - webwork. as the configuration properties prefix -> struts. - ww:

WebWork and LGPL dependencies

Some of the LGPL dependencies were already moved out of the main build process. As far as I could see the hibernate dep can completely be removed, cause there is no hibernate specific code in the codebase, just within the wikidocs. Next I just walked through the UI components of webworks tag

Re: WebWork renaming strategy *revised*

Don, I think using Struts Ti on the one hand and Struts Action 2 on the other as a name will lead to some confusion. Ti as a codename is great, but for the codebase I would prefer Action2. > - com.opensymphony.webwork package -> org.apache.struts.ti > - WebWork* classes -> Struts* > - WebWork