On Mon, Dec 28, 2009 at 2:16 PM, Paul Benedict <pbened...@apache.org> wrote: > Having XWork as a separate module is actually preferred, but only > because it's a better design decision. It will create a clear > separation of concerns within the code base. Now with that said, XWork > should be a *child* module of Struts -- not a separate release. > > Paul
When you (and Martin) are indicating a "child" of Struts, I assume you mean for it to be a child outside of Struts2. I am a team player and I'm willing to set it up, whatever the consensus, but I would really prefer for it to be a child of Struts2. I understand the implications of supporting it, etc. But, the biggest gripe (and *my* motivation for voting to move it over) is that we often wait to release Struts2 because we need a release of XWork. Not to knock Rainer, but sometimes this process takes a while. If it is a part of the Struts2 umbrella, then the release process outlined in the wiki will still apply, but everything (including xwork artifacts) will go out at once. Plus, one of my tasks for Struts 2.2 is to take advantage of maven's dependencyManagement and pluginManagement. We could probably work that into the struts-master, but I hate to push changes to Struts 1, since I don't use it much. I would just like to balance making our lives easier against other factors. In the end, if we make managing this beast easier we can move on things faster. I know that "fast" isn't necessarily a goal, but I'd still like to try to get to KISS so that potential patch-makers aren't so intimidated by our code and build process. -Wes -- Wes Wannemacher Head Engineer, WanTii, Inc. Need Training? Struts, Spring, Maven, Tomcat... Ask me for a quote! --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
