The structure your propose is not wrong... depending on your lifecycle, it may not be optimal.
Remember that the remote maven repository that you deploy your binary artifacts to will always have commons-1.0 The structure you're suggesting may be easier to work with when you regularly need to go back and do a patch of commons-1.0 to commons-1.0.1 for releasing webapp1-2.0 while webapp2-2.0 will use commons-2.0. If you just need to keep webapp1-x.y using commons-1.0 and if it needs a newer version you'll go all the way to the latest, then you can keep everything in the one trunk -Stephen On Sat, Jul 19, 2008 at 8:56 PM, James Dasher <[EMAIL PROTECTED]> wrote: > I am trying to get my hands around how to reconcile the multi-module setup > maven seems to suggest for basic webapps with a subversion repository. All > the examples seem to show a parent pom with 2 or more child poms. > > I have a requirement that two separate webapps be built using a common > module. > I have a second requirement that the two webapps may end up using separate > version levels of this common module, which will be under common development > by the two teams. > The book seems to suggest the following layout. > > /pom.xml > /commons/ > /commons/pom.xml > /webapp1/ > /webapp1/pom.xml > /webapp2/ > /webapp2/pom.xml > > So how do I handle this within my scm repository? subversion seems to > suggest the following: > > /main/branches > /main/tags > /main/trunk > /commons/branches > /commons/tags > /commons/trunk > /webapp1/branches > /webapp1/tags > /webapp1/trunk > /webapp2/branches > /webapp2/tags > /webapp2/trunk > > And then have the individual developers selectively checkout this flat > structure into the nested structure above. > > Keep in mind I may need to do a build of webapp2 with commons-1.0 and a > build of webapp1 with commons 2.0. > Am I on the wrong track here? > > -JFD > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
