Well, my suggestion of org.apache.struts.web as the package name (in anticipation of XWork becoming something like org.apache.struts.core) actually achieves #3 without the problems you have mentioned in #3, since (as far as I know) org.apache.struts.web does not conflict with existing classes.
I would note too that our philosophy of what to do with XWork generally plays importantly here. For example, some of the classes named Webwork* are done so, because they are versions of XWork counterparts, such as WebworkSpringObjectFactory. If Webwork -> SAF 2.0 Web and XWork -> SAF 2.0 Core, for example, it might be better to rename WebworkSpringObjectFactory WebSpringObjectFactory. That's why I think it important to determine what we are doing with XWork sooner rather than later. Gabe ----- Original Message ---- From: Ted Husted <[EMAIL PROTECTED]> To: Struts Developers List <dev@struts.apache.org> Sent: Sunday, March 26, 2006 9:33:14 AM Subject: Re: WebWork renaming strategy *revised* On 3/25/06, Ted Husted <[EMAIL PROTECTED]> wrote: > 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 there's an > > "action2" package lying around, that would be pretty awkward. Though, the reason we would have an Version 3 would be because the classes were incompatible with Version 2. If the new classes can co-exist with the old, then there would be no reason to roll the major version number, and everybody could continue to be Version 2, even if it were version 2.42. Over the long haul, the only alternatives seem to be 1 Version the package name 2 Contrive a new package codename for each major version (like "Catalina") 3 Discontinue the prior package and reuse the same package name Sometimes when a new major version is being released, it is expected to supercede the old, and people are not expected to use the old verison and new version together. In this case, we want to leave open the possibility of people deploying Action 1 and Action 2 classes in the same web application. So, we are left with options 1 and 2. But, I think as many people are uncomfortable with codenames as people are with versioning package names, leaving option 1. This is off-topic, but, speaking of versions, it will be intereseting to see what comes of Phil Zolio's Strecks, when it is released. * http://www.realsolve.co.uk/site/strecks/ If there were interest, an Action 1 for Java 5 might be a good reason to go from Action 1.3 onto Action 1.4. -Ted. --------------------------------------------------------------------- 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]
