Since I've been involved in these discussions today, I wanted to "put my money where my (rather substantially large) mouth is" and offer up myself to do some actual work.
If there's anything you guys can pawn off on me, I wouldn't mind being involved in some small way. I don't think I could sign up for any major pieces at the moment, but if you have some things you might be able to offload to me, you'll have my best effort :)
Here's a pretty self-contained chunk that I haven't gotten to: see if you can make the mailreader app work with the nightly builds. I started on that last night, and at least got the "examples" working with "maven dist".
Note that that section of the repository is still not necessarily perfect, so you may be flushing out more things we need to do to "finish" the reorg in that area.
If we take changes to Action and ActionForm off the table until 1.4, then we might be nearing a good point for a candidate beta release. No action has happened on switching out the message resources front, but that's not something I care enough about to want to delay things. I agree that ViewContext should get in. I'd even consider laying off of "ActionCommand" as a possible 1.3 extension but not critical to starting candidate releases flowing.
I have a few other small things I'd like to do:
* write a simple command which terminates process-action when the form is invalid but which is independent of other commands, and updating the commands which fall after to no longer worry about the state of the forms validity (or maybe not so simple and use JEXL to evaluate an arbitrary expression against the Context to abort, which I think has good potential for general usefulness.)
* consider the best way to package a tiles-chain-config.xml in some JAR so that users don't have to handle the XML in order to use Tiles; the only real issue is how annoying it might be to have a near-copy of the chain-config.xml in the tiles repository, but anything much else is getting more complicated than its worth. Maybe for now, we just accept that and move on.
* revise whatever parts of the user guide need revising to help people understand the changes
* spend at least a little time considering extensions to ForwardConfig to better support form prepopulation and "PagePrep", rather than re-rolling a homegrown variant for Struts 1.3 (See archived discussions on "ViewController" and "PagePrep", etc)
So, Frank, if you or anyone else finds any of those intriguing, there's another chance for doing some actual work.
The simplest thing that *anyone* can do would be to start trying to plug the nightly build into applications and (a) help identify any challenges which should be documented and (b) flush out bugs. The intention is that Struts 1.3 will be drop-in compatible with any existing Struts 1.2 app which uses the default request processor, and will require only minimal changes to drop it in to a Struts 1.2 app which uses the TilesRequestProcessor. Verifying/testing that intention will require real-world field-testing.
Joe
--
Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "Narrow minds are weapons made for mass destruction" -The Ex
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
