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

+1 (user vote) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Craig McClanahan Sent: Thursday, December 01, 2005 11:02 PM To: Struts Developers List Subject: [VOTE] Confirm Shale 1.0.0 Test Build Release Plan All of the outstanding issues have been account

Re: [Standalone Tiles] Major Refactoring (Long)

On 12/1/05, Joe Germuska <[EMAIL PROTECTED]> wrote: > I think we could publish nightly (or intermittent) snapshots to the > Apache repository (http://cvs.apache.org/repository/) I think that > the hope is to avoid people treating it like an ibiblio mirror (i.e. > we would only publish snapshots a

[EMAIL PROTECTED]: Project struts-taglib (in module struts) failed

To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project struts-taglib has an issue affecting its community integration. This issue affect

[EMAIL PROTECTED]: Project struts-taglib (in module struts) failed

To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project struts-taglib has an issue affecting its community integration. This issue affect

Re: [Standalone Tiles] Major Refactoring (Long)

On 12/1/05, Greg Reddin <[EMAIL PROTECTED]> wrote: > I forgot about the TLD. I haven't even looked at that yet. As for > the website, there's really not one. I personally don't want to > maintain two versions of the doc right now: the struts-tiles and > Standalone. So I'm doing doc in struts-t

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

On 12/1/05, Craig McClanahan <[EMAIL PROTECTED]> wrote: > All of the outstanding issues have been accounted for -- it's time to > release the initial test build of Shale! Given the amount of time since the > 1.0.0 release plan was first proposed, I'd like to call for a vote > confirming it: > >

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

+1 On 12/1/05, Craig McClanahan <[EMAIL PROTECTED]> wrote: > All of the outstanding issues have been accounted for -- it's time to > release the initial test build of Shale! Given the amount of time since the > 1.0.0 release plan was first proposed, I'd like to call for a vote > confirming it: -

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

+1. Looks like a plan to me. -- Martin Cooper On 12/1/05, Craig McClanahan <[EMAIL PROTECTED]> wrote: > > All of the outstanding issues have been accounted for -- it's time to > release the initial test build of Shale! Given the amount of time since > the > 1.0.0 release plan was first proposed

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

+1 On 12/1/05, Laurie Harper <[EMAIL PROTECTED]> wrote: > +1 (non-binding) > > L. > > Craig McClanahan wrote: > > All of the outstanding issues have been accounted for -- it's time to > > release the initial test build of Shale! Given the amount of time since the > > 1.0.0 release plan was first

Re: [Standalone Tiles] Major Refactoring (Long)

At 7:45 PM -0500 12/1/05, Laurie Harper wrote: Wendy Smoak wrote: I'm planning to work on the Maven build. Some combination of getting the version number into the filename (I think right now it should be tiles-core-0.2-SNAPSHOT) and possibly adding a third piece to the version number should all

Re: [Standalone Tiles] Major Refactoring (Long)

On 12/1/05, Greg Reddin <[EMAIL PROTECTED]> wrote: > > Anyway, maybe now we're far enough along I can wiki up a > roadmap and there will be a more definitive set of things for > willing hands to do. > I must echo Sean's comments, and thanks for the efforts! IMO, this wiki page will be a good thi

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

+1 (non-binding) L. Craig McClanahan wrote: All of the outstanding issues have been accounted for -- it's time to release the initial test build of Shale! Given the amount of time since the 1.0.0 release plan was first proposed, I'd like to call for a vote confirming it: http://wiki.apache.

Re: [Standalone Tiles] Major Refactoring (Long)

Wendy Smoak wrote: I'm planning to work on the Maven build. Some combination of getting the version number into the filename (I think right now it should be tiles-core-0.2-SNAPSHOT) and possibly adding a third piece to the version number should allow us to publish snapshots that don't get overwr

svn commit: r351542 - in /struts/sandbox/trunk/ti: ./ jars/ phase2/ phase2/jars/ phase2/wars/ phase2/xdocs/ wars/ xdocs/

Author: mrdon Date: Thu Dec 1 16:43:31 2005 New Revision: 351542 URL: http://svn.apache.org/viewcvs?rev=351542&view=rev Log: Moving existing Struts Ti to phase 2 directory Added: struts/sandbox/trunk/ti/phase2/ struts/sandbox/trunk/ti/phase2/LICENSE.txt - copied unchanged from r351

Re: Milestones proposal: Step 1 (revised)

Hubert Rabago wrote: On 12/1/05, Don Brown <[EMAIL PROTECTED]> wrote: If we add the "TBD" milestone, I encourage everyone to only add tickets to it if it is a clear, reachable goal that we want to achieve. While I'm afraid it will attract stagnant tickets no one cares about, I understand some

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

+1 (non-binding, "its about time" user vote) -Rahul On 12/1/05, Craig McClanahan <[EMAIL PROTECTED]> wrote: > All of the outstanding issues have been accounted for -- it's time to > release the initial test build of Shale! Given the amount of time since the > 1.0.0 release plan was first propos

Re: Milestones proposal: Step 1 (revised)

On 12/1/05, Don Brown <[EMAIL PROTECTED]> wrote: > If we add the "TBD" milestone, I encourage everyone to only add tickets to it > if > it is a clear, reachable goal that we want to achieve. While I'm afraid it > will > attract stagnant tickets no one cares about, I understand some folks find it

Milestones proposal: Step 1 (revised)

Incorporating the helpful feedback, here are the revised step 1 changes: Milestone changes - Add a "TBD" milestone - Remove all "Family" milestones and move their bugs to "TBD" - Rename "(.*) Milestone" to \1 (redundant w/o the family ones) - Add milestones: 1.2.7, 1.2.8, 1.2.9, 1.3.1, 1.4

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

+1 (non-binding) On Dec 1, 2005, at 4:02 PM, Craig McClanahan wrote: All of the outstanding issues have been accounted for -- it's time to release the initial test build of Shale! Given the amount of time since the 1.0.0 release plan was first proposed, I'd like to call for a vote confirmin

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

+1 from Gary VanMatre -- Original message -- > All of the outstanding issues have been accounted for -- it's time to > release the initial test build of Shale! Given the amount of time since the > 1.0.0 release plan was first proposed, I'd like to call for a vote > con

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

+1 Craig McClanahan wrote: All of the outstanding issues have been accounted for -- it's time to release the initial test build of Shale! Given the amount of time since the 1.0.0 release plan was first proposed, I'd like to call for a vote confirming it: http://wiki.apache.org/struts/ShaleRe

[VOTE] Confirm Shale 1.0.0 Test Build Release Plan

All of the outstanding issues have been accounted for -- it's time to release the initial test build of Shale! Given the amount of time since the 1.0.0 release plan was first proposed, I'd like to call for a vote confirming it: http://wiki.apache.org/struts/ShaleRelease100 At this time, I woul

svn commit: r351486 - /struts/shale/tags/STRUTS-SHALE_1.0.0/

Author: craigmcc Date: Thu Dec 1 13:46:42 2005 New Revision: 351486 URL: http://svn.apache.org/viewcvs?rev=351486&view=rev Log: Tag the 1.0.0 test build. Added: struts/shale/tags/STRUTS-SHALE_1.0.0/ - copied from r351483, struts/shale/trunk/ --

Re: svn commit: r351483 - /struts/shale/trunk/default.properties

On 12/1/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Log: > Flip the default version number for the 1.0.0 test release. Ack ... that should be test *build* not test *release* to be consistent with the nomenclature we agreed to. Craig

svn commit: r351483 - /struts/shale/trunk/default.properties

Author: craigmcc Date: Thu Dec 1 13:42:19 2005 New Revision: 351483 URL: http://svn.apache.org/viewcvs?rev=351483&view=rev Log: Flip the default version number for the 1.0.0 test release. Modified: struts/shale/trunk/default.properties Modified: struts/shale/trunk/default.properties URL: h

Re: [Standalone Tiles] Major Refactoring (Long)

On Dec 1, 2005, at 2:15 PM, Craig McClanahan wrote: One thing we should probably do is talk a bit about snapshots during the intermediate time period while the codebase is unstable. It doesn't make sense to me to publish tiles-core-SNAPSHOT.jar artifacts to ibiblio.org, for example, since

Re: [Standalone Tiles] Major Refactoring (Long)

On Dec 1, 2005, at 2:52 PM, Wendy Smoak wrote: I can also work on the TLD-- I think I was waiting for a decision on which attributes will be kept, but I'll go ahead and move the documentation into it. And, of course, publish the website. I forgot about the TLD. I haven't even looked at that

DO NOT REPLY [Bug 25527] - [fileupload] process lynx linemode browser's multipart form post too!

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: [Standalone Tiles] Major Refactoring (Long)

On 12/1/05, Craig McClanahan <[EMAIL PROTECTED]> wrote: > One thing we should probably do is talk a bit about snapshots during the > intermediate time period while the codebase is unstable. It doesn't make > sense to me to publish tiles-core-SNAPSHOT.jar artifacts to ibiblio.org, for > example, s

Re: [Standalone Tiles] Major Refactoring (Long)

One thing we should probably do is talk a bit about snapshots during the intermediate time period while the codebase is unstable. It doesn't make sense to me to publish tiles-core-SNAPSHOT.jar artifacts to ibiblio.org, for example, since they in effect replace the previous snapshot. People who w

Re: [Standalone Tiles] Major Refactoring (Long)

On 12/1/05, Greg Reddin <[EMAIL PROTECTED]> wrote: > > > On Dec 1, 2005, at 1:47 PM, Sean Schofield wrote: > > > I can't believe how much you like to punish yourself! Is anyone else > > helping you with this massive effort? > > Well, I brought this on myself :-) I've been a big fan of Tiles ever

Re: [Standalone Tiles] Major Refactoring (Long)

On Dec 1, 2005, at 1:47 PM, Sean Schofield wrote: I can't believe how much you like to punish yourself! Is anyone else helping you with this massive effort? Well, I brought this on myself :-) I've been a big fan of Tiles ever since I first used it. When people started talking about packa

Re: Milestones proposal: Step 1

On 11/30/05, Don Brown <[EMAIL PROTECTED]> wrote: > > I take it the "Target tickets to milestones" proposal passed, and thanks > for all the feedback. As the first step, could Martin or Craig please > make the following Bugzilla changes: > > Milestone changes > - Remove all "Family" milestones >

Re: Commit template (was [PROPOSAL] Target tickets to milestones and use as roadmap)

On 12/1/05, Don Brown <[EMAIL PROTECTED]> wrote: > > Sure, but my only concern is many svn log analysis tools will only display > the > first line of a commit message, so I think it should contain some sort of > summary. As for Contributed By, I was thinking only to put that there if > there > was

Re: [Standalone Tiles] Major Refactoring (Long)

I can't believe how much you like to punish yourself! Is anyone else helping you with this massive effort? I'd offer to help but my workload is at about 250% capacity right now. When things stablize I'll take things for a spin in Shale. sean On 12/1/05, Greg Reddin <[EMAIL PROTECTED]> wrote: >

Re: Tough Questions on Struts and Webwork Integration

Definitely getting a bit off topic, but... :) Matthew Porter, who works for Contegix, recently wrote an article that I think is very relevant: http://www.porterhome.com/blog/matthew/2005/11/15/1132088805733.html Contegix has tried to address these "single points of failure" by providing a broad

DO NOT REPLY [Bug 25527] - [fileupload] process lynx linemode browser's multipart form post too!

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: [PROPOSAL] Target tickets to milestones and use as roadmap

+1 on Don's proposals to improve tracking and roadmap. +0 on JIRA ... Bugzilla makes cross-bug references with Commons projects we depend on a little easier, but that is less important now (most of the Commons packages we use are pretty stable) than it was earlier. Craig On 11/29/05, Don Brown

Re: Milestones proposal: Step 1

On 12/1/05, Don Brown <[EMAIL PROTECTED]> wrote: > > In my opinion, it would be simpler to assign those tickets to the next > major/minor release, forcing developers to assess when that milestone is > on deck > whether the ticket will actually get fixed in this one or moved further > down. > The pr

Re: Tough Questions on Struts and Webwork Integration

On 12/1/05, Ted Husted <[EMAIL PROTECTED]> wrote: > > On 11/30/05, Martin Cooper <[EMAIL PROTECTED]> wrote: > > I am very much against taking ASF content off-site, as it were. We have > a > > perfectly good wiki, and that's where our content should be. I know > there > > are a bunch of Confluence

Re: Milestones proposal: Step 1

+1 to new "Probably never" or perhaps something more politically correct state. Don Laurie Harper wrote: There does need to be a distinction, though, between 'probably never' and new tickets, not yet assigned to a milestone. I'm not that familiar with Bugzilla, though; maybe the Status field i

Re: Milestones proposal: Step 1

There does need to be a distinction, though, between 'probably never' and new tickets, not yet assigned to a milestone. I'm not that familiar with Bugzilla, though; maybe the Status field is enough to handle that? L. Don Brown wrote: In my opinion, it would be simpler to assign those tickets t

DO NOT REPLY [Bug 37741] - [tiles] TilesServlet does not load all servlet parameters

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: [Standalone Tiles] TilesRequestProcessor and TilesPlugin

On Dec 1, 2005, at 11:31 AM, Joe Germuska wrote: I haven't looked at how the TilesServlet deals with looking up tiles definitions from request paths, but I can imagine a few ways to allow you to configure this if you wanted it. Certainly there should be flexibility and user choice in how

DO NOT REPLY [Bug 37741] New: - [tiles] TilesServlet does not load all servlet parameters

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

[Standalone Tiles] Major Refactoring (Long)

I have just checked in a sweeping refactoring of the Standalone Tiles codebase. Many may see it and immediately hurl cruise missiles in my general direction :-) Please do, I can take it. First and foremost however, I ask that you remember this is the sandbox. I'm just experimenting and

Re: [Standalone Tiles] From Struts-Tiles to Tiles-standalone incompatibilities

Greg Reddin wrote: > > Yes, I understand, and I still have your messages from about a month ago in my inbox and have not forgotten your requests, though I'm not sure I fully understand what you are trying to do. The typical scenario is: 1) take the HttpServletRequest, in particular a bean (in se

DO NOT REPLY [Bug 36037] - Allow query strings and anchors when returning forwards from Action

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

DO NOT REPLY [Bug 36037] - Allow query strings and anchors when returning forwards from Action

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

DO NOT REPLY [Bug 36037] - Allow query strings and anchors when returning forwards from Action

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: [Standalone Tiles] TilesRequestProcessor and TilesPlugin

At 5:27 PM +0100 12/1/05, <[EMAIL PROTECTED]> wrote: Joe Germuska wrote: I would think that if you were using the TilesServlet mapped to handle requests for "*.tiles" then would just become or something similar depending on how the TilesServlet maps paths to definitions.

DO NOT REPLY [Bug 36037] - Allow query strings and anchors when returning forwards from Action

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: Commit template (was [PROPOSAL] Target tickets to milestones and use as roadmap)

Sure, but my only concern is many svn log analysis tools will only display the first line of a commit message, so I think it should contain some sort of summary. As for Contributed By, I was thinking only to put that there if there was a patch, because otherwise, it is easy to scrape the report

DO NOT REPLY [Bug 36037] - Allow query strings and anchors when returning forwards from Action

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: Milestones proposal: Step 1

In my opinion, it would be simpler to assign those tickets to the next major/minor release, forcing developers to assess when that milestone is on deck whether the ticket will actually get fixed in this one or moved further down. The problem with this "1.1 Family" is evident in Bugzilla where we

Re: [Standalone Tiles] From Struts-Tiles to Tiles-standalone incompatibilities

On Dec 1, 2005, at 10:21 AM, <[EMAIL PROTECTED]> wrote: Hello (again) :-) I am in the process of porting a product based upon (Struts) Tiles called "Dimensions". It makes intensive use of "FactorySet" class. I am trying to port a simple example to Tiles Standalone, but I'm having a growin

svn commit: r350273 - in /struts/sandbox/trunk/tiles: ./ src/conf/ src/java/org/apache/tiles/ src/java/org/apache/tiles/definition/ src/java/org/apache/tiles/digester/ src/java/org/apache/tiles/servle

Author: greddin Date: Thu Dec 1 08:50:58 2005 New Revision: 350273 URL: http://svn.apache.org/viewcvs?rev=350273&view=rev Log: Major Tiles Refactoring - API Cleanup - Added more unit tests. - Removed old compatibility layer components. - Cleaned up API by shrinking layers - Replaced variaous A

Re: [Standalone Tiles] From Struts-Tiles to Tiles-standalone incompatibilities

I was wondering where I might hack the code when I saw this in TilesUtilImpl: if (definition == null) { if (!factory.isLocaleProcessed(request.getLocale())) { // FIXME This will modify the factory as well as the definitions // bu

Re: [Standalone Tiles] TilesRequestProcessor and TilesPlugin

Joe Germuska wrote: > > I would think that if you were using the TilesServlet mapped to handle requests for "*.tiles" then > >> > > > would just become > >> > > > or something similar depending on how the TilesServlet maps paths to definitions. > > I haven't tried this, but it seems to make sens

[Standalone Tiles] From Struts-Tiles to Tiles-standalone incompatibilities

Hello (again) :-) I am in the process of porting a product based upon (Struts) Tiles called "Dimensions". It makes intensive use of "FactorySet" class. I am trying to port a simple example to Tiles Standalone, but I'm having a growing headache! :-P So let's start: 1) First of all I noticed that yo

Re: [Standalone Tiles] TilesRequestProcessor and TilesPlugin

At 12:54 PM +0100 12/1/05, <[EMAIL PROTECTED]> wrote: I noticed that TilesRequestProcessor and TilesPlugin have disappeared from Tiles standalone. I know that TilesPlugin absence could be replaced with TilesServlet (I think it only initializes the definitions factory, correct me if I am wrong) bu

Re: Tough Questions on Struts and Webwork Integration

On 11/30/05, Joe Germuska <[EMAIL PROTECTED]> wrote: > Presumably the Struts committers are going to heavily involved in the > compatibility, so if for no other reason, it will be easier for us to > work on that in an Apache.org repository. I plan to be very heavily involved in compatiblity and mi

DO NOT REPLY [Bug 25527] - [fileupload] process lynx linemode browser's multipart form post too!

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

DO NOT REPLY [Bug 25527] - [fileupload] process lynx linemode browser's multipart form post too!

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: [Standalone Tiles] TilesRequestProcessor and TilesPlugin

On Dec 1, 2005, at 5:54 AM, <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> wrote: I noticed that TilesRequestProcessor and TilesPlugin have disappeared from Tiles standalone. Yes, these are the components of Tiles that provide integration with Struts 1.2.x and earlier. They were removed to b

Re: Tough Questions on Struts and Webwork Integration

On 12/1/05, Patrick Lightbody <[EMAIL PROTECTED]> wrote: > I would volunteer that Contegix, the hosting company that handles > OpenSymphony, OpenQA, Spring, Atlassian, Jive, Cenqua, and others > would be happy to help Struts (and Apache, I suppose) in the future. > As I mentioned to Ted and Don, I'

Re: Tough Questions on Struts and Webwork Integration

I think doing the compatibility layer after the code is imported in to Apache makes sense. WebWork has various developers who go in spurts of involvement. The two core developers are Jason and myself. Lately, there have been about 3 or 4 others pretty actively involved, but I'm sure they wo

Re: Tough Questions on Struts and Webwork Integration

The docs are getting a _lot_ better. We're doing a 2.2 beta 4 release today that will have a bunch more docs. On Nov 30, 2005, at 10:15 AM, Don Brown wrote: Pilgrim, Peter wrote: If I understand you rightly the traditional `RequestProcessor' derived process flow, namely ActionServl

Re: Tough Questions on Struts and Webwork Integration

I totally understand Martin's concerns. Let's not try to bite off more than we can chew just yet. We've got enough on our hands with the WebWork/Struts merger :) I would volunteer that Contegix, the hosting company that handles OpenSymphony, OpenQA, Spring, Atlassian, Jive, Cenqua, and othe

Re: [PROPOSAL] Target tickets to milestones and use as roadmap

> We also create an artificial milestone called "Future" that we assign > things that are of the wish-list variety. We always schedule it after > all of the other versions so that it doesn't bog down the roadmap displays. Same here. We use TBD. > -Paul sean ---

Re: [Standalone Tiles] TilesRequestProcessor and TilesPlugin

Whoops I have to correct myself. I use: mapping.findForward("success"); while in struts-config.xml I put this: But the question is the same ;-) [EMAIL PROTECTED] wrote: >I noticed that TilesRequestProcessor and TilesPlugin have disappeared from >Tiles standalone. >I know that TilesPlugin absenc

[Standalone Tiles] TilesRequestProcessor and TilesPlugin

I noticed that TilesRequestProcessor and TilesPlugin have disappeared from Tiles standalone. I know that TilesPlugin absence could be replaced with TilesServlet (I think it only initializes the definitions factory, correct me if I am wrong) but TilesRequestProcessor is useful for Struts users. I wa

Re: Tough Questions on Struts and Webwork Integration

On 11/30/05, Martin Cooper <[EMAIL PROTECTED]> wrote: > I am very much against taking ASF content off-site, as it were. We have a > perfectly good wiki, and that's where our content should be. I know there > are a bunch of Confluence fans out there, and maybe it's a better product in > some ways.

Re: Commit template (was [PROPOSAL] Target tickets to milestones and use as roadmap)

On 11/30/05, Don Brown <[EMAIL PROTECTED]> wrote: > There was in the CVS days, and I don't believe I've seen it since. I'm > thinking > something simple like: > Adding this new feature > PR: 234 > Type: (fix, add, update, documentation) > Contributed By: Sarah Jones I'd suggest somthing like thi

Re: Milestones proposal: Step 1

On 12/1/05, Niall Pemberton <[EMAIL PROTECTED]> wrote: > Did we agree anything on bugs which we don't want to allocate to a > milestone - my preference is a "probably never" or "un-allocated" > milestone - something we can query on. Personally I don't like "LATER" > resolutions - IMO thats not a "r

Re: Milestones proposal: Step 1

On 12/1/05, Don Brown <[EMAIL PROTECTED]> wrote: > I take it the "Target tickets to milestones" proposal passed, and thanks > for all the feedback. As the first step, could Martin or Craig please > make the following Bugzilla changes: > > Milestone changes > - Remove all "Family" milestones > -