DO NOT REPLY [Bug 16804] - html:text tag has no filter attribute

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

Re: [VOTE] Confirm Shale 1.0.0 Test Build Release Plan

Dave Durham wrote: > I certainly prefer to have the source code bundled along with the binaries. > > As everyone on the list probably knows, Eclipse and other IDEs require the > source code be "attached" to the libraries for certain features, such as > in-line documentation and ctrl-clicking in

Managing Snapshots in the Maven Repo (was Re: [Standalone Tiles] Major Refactoring (Long))

> I think we should disclaim any responsibility for maintaining specific JARs in the cvs.apache.org repository; if people are depending on SNAPSHOTS, they should be prepared for things possibly being removed. Is that fair? That certainly makes some logical sense ... but it has a down side

svn commit: r353917 - /struts/scripting/tags/STRUTS-SCRIPTING_1.0.0/

Author: mrdon Date: Sun Dec 4 13:42:19 2005 New Revision: 353917 URL: http://svn.apache.org/viewcvs?rev=353917&view=rev Log: Tagging the 1.0.0 release of Struts Scripting Added: struts/scripting/tags/STRUTS-SCRIPTING_1.0.0/ - copied from r353916, struts/scripting/trunk/ -

svn commit: r353918 - /struts/scripting/trunk/xdocs/changes.xml

Author: mrdon Date: Sun Dec 4 13:47:14 2005 New Revision: 353918 URL: http://svn.apache.org/viewcvs?rev=353918&view=rev Log: Adding release date to changes Modified: struts/scripting/trunk/xdocs/changes.xml Modified: struts/scripting/trunk/xdocs/changes.xml URL: http://svn.apache.org/viewc

svn commit: r353919 - /struts/scripting/tags/STRUTS-SCRIPTING_1.0.0/trunk/

Author: mrdon Date: Sun Dec 4 13:47:48 2005 New Revision: 353919 URL: http://svn.apache.org/viewcvs?rev=353919&view=rev Log: Retagging 1.0.0 release (there's always one more thing...) Added: struts/scripting/tags/STRUTS-SCRIPTING_1.0.0/trunk/ - copied from r353918, struts/scripting/tru

Uploading release (where?)

Where do I upload the Struts Scripting 1.0.0 release to? Maven doesn't seem to be setup to do it automatically, but I don't see a good place for it anyways. It seems like the directories in /www/cvs.apache.org/dist/ are only TLP's, but I don't see a clear place in the Struts directory. Didn'

[Struts Wiki] Update of "StrutsScriptingRelease100" by DonBrown

Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by DonBrown: http://wiki.apache.org/struts/StrutsScriptingRelease100 --

[Struts Wiki] Trivial Update of "StrutsScriptingRelease100" by DonBrown

Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by DonBrown: http://wiki.apache.org/struts/StrutsScriptingRelease100 --

Bug report for Struts [2005/12/04]

+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned

Re: Uploading release (where?)

On 12/4/05, Don Brown <[EMAIL PROTECTED]> wrote: > > Where do I upload the Struts Scripting 1.0.0 release to? Maven doesn't > seem to be setup to do it automatically, but I don't see a good place > for it anyways. It seems like the directories in > /www/cvs.apache.org/dist/ are only TLP's, but I

svn commit: r353937 - /struts/shale/trunk/xdocs/features-commons-validator.xml

Author: wsmoak Date: Sun Dec 4 15:35:01 2005 New Revision: 353937 URL: http://svn.apache.org/viewcvs?rev=353937&view=rev Log: Added links to commonsValidator and validatorScript tag reference pages. Modified: struts/shale/trunk/xdocs/features-commons-validator.xml Modified: struts/shale/tru

svn commit: r353938 - in /struts/shale/trunk/build: clay-plugin/project.xml core-library/project.xml core-test/project.xml mailreader/project.xml project.xml spring/project.xml test-framework/project.

Author: wsmoak Date: Sun Dec 4 15:37:52 2005 New Revision: 353938 URL: http://svn.apache.org/viewcvs?rev=353938&view=rev Log: Changed version number to 1.0.0 Modified: struts/shale/trunk/build/clay-plugin/project.xml struts/shale/trunk/build/core-library/project.xml struts/shale/trun

svn commit: r353942 - in /struts/shale/trunk: build/project.properties xdocs/pdf-navigation.xml

Author: wsmoak Date: Sun Dec 4 16:06:13 2005 New Revision: 353942 URL: http://svn.apache.org/viewcvs?rev=353942&view=rev Log: Added config for PDF generation. (Currently requires building the PDF plugin v2.5-SNAPSHOT from source.) Added: struts/shale/trunk/xdocs/pdf-navigation.xml (with

svn commit: r353943 - in /struts/shale/trunk: clay-plugin/xdocs/navigation.xml core-library/xdocs/navigation.xml xdocs/navigation.xml

Author: wsmoak Date: Sun Dec 4 16:13:30 2005 New Revision: 353943 URL: http://svn.apache.org/viewcvs?rev=353943&view=rev Log: Make navigation hrefs absolute, per the Maven docs. http://maven.apache.org/maven-1.x/using/site.html Modified: struts/shale/trunk/clay-plugin/xdocs/navigation.xml

Re: [VOTE] Confirm Shale 1.0.0 Test Build Release Plan

This may seem [OT] to some people on the list, but I hope it drives another nail into FormDef's coffin. Seriously, who in their right mind would declare a bean with Java? Ryan Stewart wrote: I'll second that. I'm hardly "new," but I much prefer to have everything packaged as one unit as well

[ti] Struts Action 1.x migration tools

I've gone back and forth how and to what level of detail Struts Ti can/should support Struts Action 1.x applications. When I say Struts Ti, at this point, I'm referring to WebWork 2.2 since we haven't imported the code yet. Below is my thoughts that I invite comments on. Basically, I see thr

Re: [ti] Struts Action 1.x migration tools

Don, I think you're right: option #2 sounds the most appealing. Though, I think we won't know for sure until we get our hands on things and try it out :) I believe with Ted working on the MailReader application, we might have a chance to put this hypothesis to the test, right? Patrick On

[VOTE] Struts Scripting 1.0.0 Quality

After addressing all issues found with the Struts Scripting 1.0.0 test build, I've built, tagged and deployed the Struts Scripting 1.0.0 build. Once you have had a chance to form an opinion on the quality of this build, please respond to the following vote.

[Struts Wiki] Update of "StrutsScriptingRelease100" by DonBrown

Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by DonBrown: http://wiki.apache.org/struts/StrutsScriptingRelease100 The comment on the change is: Removing "update aquiring page" for build list sin

Re: [ti] Struts Action 1.x migration tools

Don Brown wrote: I've gone back and forth how and to what level of detail Struts Ti can/should support Struts Action 1.x applications. When I say Struts Ti, at this point, I'm referring to WebWork 2.2 since we haven't imported the code yet. Below is my thoughts that I invite comments on. Ba

Re: [ti] Struts Action 1.x migration tools

I'd classify all those goals as those of approach 1, which is building 1.x support right in Ti. What I'm coming to the conclusion of is that it would be a lot of work, be prone to surprise errors, and ultimately futile. If my 1.x app is running fine, what would I gain by trying to run it on a

Re: [ti] Struts Action 1.x migration tools

Patrick Lightbody wrote: Don, I think you're right: option #2 sounds the most appealing. Though, I think we won't know for sure until we get our hands on things and try it out :) I believe with Ted working on the MailReader application, we might have a chance to put this hypothesis to the t

Re: Uploading release (where?)

Thanks, I went ahead and created a 'scripting' directory. I noticed commons does things different by not creating version directories, but I did to follow Struts convention. Don Craig McClanahan wrote: On 12/4/05, Don Brown <[EMAIL PROTECTED]> wrote: Where do I upload the Struts Scripting

Re: [ti] Struts Action 1.x migration tools

I'd like to again raise what I think is the 5th option on that list... don't even bother :) With the caveat that I haven't even entirely convinced *myself* its the right answer, maybe this is the right time for a clean break where compatibility isn't a concern. I think I personally would pre