On Mon, Dec 28, 2009 at 11:37 AM, Wes Wannemacher <w...@wantii.com> wrote: > 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.
Where XWork lands up in the Struts repo, and how it gets built, have zero bearing on how it gets released (except if we see ourselves releasing it independently, which I did not think was the case). As I see it, we have a set of choices to make 1) (a) move, (b) copy, (c) create an 'external' reference for 2) (a) all of XWork, (b) just the XWork core, (c) some other subset of XWork 3) (a) to a peer of 'struts2', (b) to somewhere within 'struts2', (c) to somewhere else I believe 1c + 2a + 3a = what we have today except that it's one checkout instead of two. With that option, nothing about the build or the build documentation changes, AFAICT. Is that what we want? I don't know, I'm just suggesting that it's a low-cost way of moving forward now that the code is in our repo. I don't have a particular bias in regard to how we go about this, beyond some source control best practices. I just think we need to make sure we're all on the same page about where we want to end up. -- Martin Cooper > -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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
