Re: XWork has landed!
Are we going to rename the maven artifact names and package names for 2.2? musachy On Sun, Dec 27, 2009 at 12:39 PM, Martin Cooper mart...@apache.org wrote: On Sun, Dec 27, 2009 at 12:30 PM, Paul Benedict pbened...@apache.org wrote: I recommend we immediately SVN tag or branch the initial check in so it can be refactored appropriately. I'm not sure I see a need to do that, given that we can create a tag or branch from a specific revision at any time. However, if you feel the need, you're welcome to do that. -- Martin Cooper Paul On Sun, Dec 27, 2009 at 1:18 PM, Lukasz Lenart lukasz.len...@googlemail.com wrote: 2009/12/27 Martin Cooper mart...@apache.org: As many of you have no doubt noticed already, I've checked in the XWork code base, and added the Apache License 2.0 headers. The new XWork tree is here: Hurra!!! Thanks a lot! Regards -- Lukasz http://www.lenart.org.pl/ - 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 - 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
Re: XWork has landed!
If no one objects, i can take a stab at taking care of this tonight... I haven't looked much at Martin's check-in, but we only need to port the xwork-core artifact... So, my plan would be to copy the source to the struts2 folder as a first-class sub-project (adding it to the modules section of the struts2 parent pom). Then, if that build works out, the next check-ins can be renaming / refactoring of classes, etc. But, if xwork-core is placed in the struts2 folder, alongside struts2-core, struts2-plugins, etc., then, if nothing else, it will make releasing easier. I'd imagine that refactoring class and package names will be a bit troublesome. Although the IDE can handle most of it for us, the trick isn't the easy stuff, the trick is finding the classes that are no longer necessary and/or duplicated between codebases. Thoughts? -Wes On Mon, Dec 28, 2009 at 1:16 PM, Musachy Barroso musa...@gmail.com wrote: Are we going to rename the maven artifact names and package names for 2.2? musachy On Sun, Dec 27, 2009 at 12:39 PM, Martin Cooper mart...@apache.org wrote: On Sun, Dec 27, 2009 at 12:30 PM, Paul Benedict pbened...@apache.org wrote: I recommend we immediately SVN tag or branch the initial check in so it can be refactored appropriately. I'm not sure I see a need to do that, given that we can create a tag or branch from a specific revision at any time. However, if you feel the need, you're welcome to do that. -- Martin Cooper Paul On Sun, Dec 27, 2009 at 1:18 PM, Lukasz Lenart lukasz.len...@googlemail.com wrote: 2009/12/27 Martin Cooper mart...@apache.org: As many of you have no doubt noticed already, I've checked in the XWork code base, and added the Apache License 2.0 headers. The new XWork tree is here: Hurra!!! Thanks a lot! Regards -- Lukasz http://www.lenart.org.pl/ - 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 - 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 -- 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
Re: XWork has landed!
On Mon, Dec 28, 2009 at 10:29 AM, Wes Wannemacher w...@wantii.com wrote: If no one objects, i can take a stab at taking care of this tonight... I guess I sort of object, unless I'm the only one without a full and clear picture of the fate of this new code base that we own. I think we need to make sure we're all on the same page before we start making changes. I haven't looked much at Martin's check-in, but we only need to port the xwork-core artifact... So, my plan would be to copy the source to the struts2 folder as a first-class sub-project (adding it to the modules section of the struts2 parent pom). Then, if that build works out, the next check-ins can be renaming / refactoring of classes, etc. But, if xwork-core is placed in the struts2 folder, alongside struts2-core, struts2-plugins, etc., then, if nothing else, it will make releasing easier. I'd imagine that refactoring class and package names will be a bit troublesome. Although the IDE can handle most of it for us, the trick isn't the easy stuff, the trick is finding the classes that are no longer necessary and/or duplicated between codebases. Thoughts? What I checked in is the entire XWork repo, since XWork is now our responsibility. That is, we don't have a copy of XWork that we're maintaining, we own XWork now. We have adopted it, lock, stock and barrel. If people need enhancements to XWork, they will come to us from now on. (What we do with such requests is something we should discuss at some point in the near future.) I was envisaging that we would add XWork to the 'current' external in such a way that it would look exactly the same as it does today when someone checks it out as a peer of the 'struts2' folder. I take it this is not what you have in mind? I have to say that 'copy' is not a word I like to see in reference to source control. ;-) It implies a forking of the code base that we would need to be very sure about. Is that actually what you mean? -- Martin Cooper -Wes On Mon, Dec 28, 2009 at 1:16 PM, Musachy Barroso musa...@gmail.com wrote: Are we going to rename the maven artifact names and package names for 2.2? musachy On Sun, Dec 27, 2009 at 12:39 PM, Martin Cooper mart...@apache.org wrote: On Sun, Dec 27, 2009 at 12:30 PM, Paul Benedict pbened...@apache.org wrote: I recommend we immediately SVN tag or branch the initial check in so it can be refactored appropriately. I'm not sure I see a need to do that, given that we can create a tag or branch from a specific revision at any time. However, if you feel the need, you're welcome to do that. -- Martin Cooper Paul On Sun, Dec 27, 2009 at 1:18 PM, Lukasz Lenart lukasz.len...@googlemail.com wrote: 2009/12/27 Martin Cooper mart...@apache.org: As many of you have no doubt noticed already, I've checked in the XWork code base, and added the Apache License 2.0 headers. The new XWork tree is here: Hurra!!! Thanks a lot! Regards -- Lukasz http://www.lenart.org.pl/ - 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 - 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 -- 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
Re: XWork has landed!
I am ok with moving it to under struts as a module, to make it part of the release, so we don't have to release it (and vote!) as a separate artifact. On Mon, Dec 28, 2009 at 10:57 AM, Martin Cooper mart...@apache.org wrote: On Mon, Dec 28, 2009 at 10:29 AM, Wes Wannemacher w...@wantii.com wrote: If no one objects, i can take a stab at taking care of this tonight... I guess I sort of object, unless I'm the only one without a full and clear picture of the fate of this new code base that we own. I think we need to make sure we're all on the same page before we start making changes. I haven't looked much at Martin's check-in, but we only need to port the xwork-core artifact... So, my plan would be to copy the source to the struts2 folder as a first-class sub-project (adding it to the modules section of the struts2 parent pom). Then, if that build works out, the next check-ins can be renaming / refactoring of classes, etc. But, if xwork-core is placed in the struts2 folder, alongside struts2-core, struts2-plugins, etc., then, if nothing else, it will make releasing easier. I'd imagine that refactoring class and package names will be a bit troublesome. Although the IDE can handle most of it for us, the trick isn't the easy stuff, the trick is finding the classes that are no longer necessary and/or duplicated between codebases. Thoughts? What I checked in is the entire XWork repo, since XWork is now our responsibility. That is, we don't have a copy of XWork that we're maintaining, we own XWork now. We have adopted it, lock, stock and barrel. If people need enhancements to XWork, they will come to us from now on. (What we do with such requests is something we should discuss at some point in the near future.) I was envisaging that we would add XWork to the 'current' external in such a way that it would look exactly the same as it does today when someone checks it out as a peer of the 'struts2' folder. I take it this is not what you have in mind? I have to say that 'copy' is not a word I like to see in reference to source control. ;-) It implies a forking of the code base that we would need to be very sure about. Is that actually what you mean? -- Martin Cooper -Wes On Mon, Dec 28, 2009 at 1:16 PM, Musachy Barroso musa...@gmail.com wrote: Are we going to rename the maven artifact names and package names for 2.2? musachy On Sun, Dec 27, 2009 at 12:39 PM, Martin Cooper mart...@apache.org wrote: On Sun, Dec 27, 2009 at 12:30 PM, Paul Benedict pbened...@apache.org wrote: I recommend we immediately SVN tag or branch the initial check in so it can be refactored appropriately. I'm not sure I see a need to do that, given that we can create a tag or branch from a specific revision at any time. However, if you feel the need, you're welcome to do that. -- Martin Cooper Paul On Sun, Dec 27, 2009 at 1:18 PM, Lukasz Lenart lukasz.len...@googlemail.com wrote: 2009/12/27 Martin Cooper mart...@apache.org: As many of you have no doubt noticed already, I've checked in the XWork code base, and added the Apache License 2.0 headers. The new XWork tree is here: Hurra!!! Thanks a lot! Regards -- Lukasz http://www.lenart.org.pl/ - 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 - 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 -- 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 - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: XWork has landed!
I thought we had reached consensus on this back in August: http://old.nabble.com/Re%3A-Let%27s-kill-xwork-%28was-Re%3A-2.1.8-release-%29-p24966742.html -Dale - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: XWork has landed!
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 - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: XWork has landed!
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
Re: XWork has landed!
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
RE: XWork has landed!
-Original Message- From: Martin Cooper Sent: Monday, December 28, 2009 15:10 To: Struts Developers List Subject: Re: XWork has landed! 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 snip/ 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. I think it would be best to have in the same source control repository, but keep it as separate as possible. We use the following tree here: /repoPerProjectGroup ./trunk ../subproject1 ../subproject2 ../subproject3 ./branches ./common ./private ./releases ./tmp Allowing subprojects to be freely independent and dependent at the same time. -Jason -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: XWork has landed!
On Mon, Dec 28, 2009 at 1:37 PM, 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. My fault for not being clear. I was intending to say XWork should be a child module (in the Maven sense) so it's actually part of Struts2 build and versioning process. Paul - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
