On Sun, 14 Mar 2004, Ted Husted wrote: > On Sun, 14 Mar 2004 11:34:10 -0600, Joe Germuska wrote: > > At 11:59 AM -0500 3/14/04, Ted Husted wrote: > >> On Fri, 12 Mar 2004 15:07:18 -0600, Joe Germuska wrote: > > No one is more gung-ho about Struts Chain than I am, but people > > should be aware that we're still just into beta with functionality. > > Using it on my latest project, I've definitely found a few pieces > > that hadn't yet been implemented. I've put in what I found missing > > -- tiles and file upload -- but there are probably some other less > > mainstream pieces that will turn out to be buggy or not even > > implemented. We would probably want to make a branching CVS tag > > for this if we do it. I don't have a lot of experience working on > > branched codebases with a distributed team, so it should be an > > interesting ride, but I think Struts Chain is far enough from ready > > that we don't have a choice. > > I'd say we could branch what we have as 1.2 and start thinking of the HEAD as 1.3. > > IMHO, the quickest way to sort out what we need to do with the Struts-Chain > RequestProcessor is to get it out there as the nightly build. [Many hands make light > work ;)] > > So, we could reserve the 1.2 for any desperate fixes (as we've done before), but do > anything resembling new development against the HEAD (1.3). > > > > Plus, we need to push commons-chain to a full release. And what > > about commons-resources? That sounded like it was pretty close. > > Looking at http://jakarta.apache.org/struts/status.html , I think > > that roadmap may be still be a good strategy -- get the resources > > transition done for 1.3, then the new request processor for 1.4. > > Can anyone summarize what's standing between here and moving to > > commons-resources? > > I think Commons Chain can move up any time we wanted. It's just a matter of floating > a vote. > > The Resources thing has been a longtime coming and should be stable. I wouldn't > hesitate to do both Resources and Struts Chain in the HEAD now.
I'm OK with Chain being promoted as is, but I'd prefer to see Resources migrate to a presence-based build (as opposed to a contrib basis) before promotion. And yes, I'm willing to make the change when I have the time to do it. ;-) -- Martin Cooper > > In general, I'm satisfied with targeting the "page prep" as a chain- > > dependent feature. If we introduce a StrutsContext as the chain > > implementation of o.a.c.chain.Context then we'll have to come up > > with a Context factory process so that the > > ComposableRequestProcessor can be given a Context instead of > > instantiating one itself. My first hunch is that it should be an > > early chain command which creates a sub-context of a specific type > > and uses it to do most of the chain processing. > > > > Joe > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
