Understood, but if you have dependencies to you sibling-modules, you'd have the same problem...
So, I'd personally always build from the root-project after a fresh check-out... And from then on it wouldn't be necessary to use the relativePath. Still, I understand your reasoning and I agree it's probably the best solution in your scenario. On Thursday 15 November 2007 15:25, Stuart McCulloch wrote: > On 15/11/2007, Roland Asmann <[EMAIL PROTECTED]> wrote: > > True. One question though: why do you use the 'relativePath'-attribute? > > This > > shouldn't be really necessary, or am I missing something here? > > say you've just checked out a fresh project tree from svn - it's not yet > been > released to any remote repository, and you have a clean local repository. > > if you went to a sub-folder and tried "mvn install" it would complain about > not > finding the parent POM (because it's not the same as the containing ".." > POM) > > the relativePath attribute tells Maven where to find the POM if it can't > find it > in the local or remote repositories - note that if the parent is the same > as the containing POM then you shouldn't need to use relativePath > > http://maven.apache.org/guides/introduction/introduction-to-the-pom.html#Ex >ample_2 > > HTH > > On Thursday 15 November 2007 14:35, Stuart McCulloch wrote: > > > On 15/11/2007, Roland Asmann <[EMAIL PROTECTED]> wrote: > > > > How about re-writing the plugin to Maven2? Then you can at least > > > > remove > > > > > > the 'modules'-part in your base-POM... > > > > > > > > Otherwise I'm afraid you're indeed stuck with the 2-way dependency. > > > > > > also note the parent doesn't have to be the same as the 'containing' > > > POM (ie. the one with the modules) > > > > > > for example, some projects place settings like dependencyManagement, > > > pluginManagement, etc. in a separate POM (say inside a 'poms' > > > directory) and have all sub-projects use this as their parent, and have > > > module POMs just to support building from the root, not for inheriting > > > settings. > > > > > > ie: > > > > > > pom.xml (has modules: poms, A, B) > > > > > > \__ poms / pom.xml > > > > > > \__ A / pom.xml (has poms as parent, relativePath ../poms) > > > > > > \__ B / pom.xml (has poms as parent, relativePath ../poms) > > > > > > this can be really useful when you have various project types inside a > > > single > > > tree, because each sub-project can inherit settings from a different > > > parent, and they won't disturb each other. > > > > > > the only tricky part is keeping the relativePath up-to-date, so that > > > > builds > > > > > can > > > work from any part of a check-out project tree... (I use my own plugin > > > > for > > > > > this) > > > > > > On Thursday 15 November 2007 12:34, Aaron Zeckoski wrote: > > > > > > If you build the 'parent' and it does not contain the > > > > 'modules'-tag, > > > > > > the > > > > > > > > > > children DO NOT get build. > > > > > > > > > > Yeah, we want to be able to build from either the parent (and build > > > > > everything) or from the child (and just build the child) but we > > > > > need the information in the parent when the child is being built. > > > > > As a result, it looks like we are stuck with the 2-way dependency > > > > > (at > > > > least > > > > > > > according to what I could understand from the maven site and the > > > > maven > > > > > > > book). > > > > > > > > > > In maven1 we created a plugin which would walk the source tree so > > > > that > > > > > > > the parents did not have to know about the children. The nice thing > > > > > about this is that you could drop a new project in the source tree > > > > and > > > > > > > it would get picked up and built automatically. All the children > > > > only > > > > > > > knew about one single master POM which provided them with a set of > > > > > properties and shared dependencies. > > > > > > > > > > I think we are going to have to just be stuck with the tight > > > > coupling > > > > > > > in maven 2 though. > > > > > I would be happy to know I am wrong on this though so feel free to > > > > > > > > correct > > > > > > > > > me. > > > > > > > > > > :-) > > > > > > > > > > -AZ > > > > > > > > > > > Just play around with it a bit, Maven is very flexible in this > > > > way. I > > > > > > do > > > > > > > > > > however believe it is described in the documentation, and pretty > > > > > > extensive if I recall correctly... > > > > > > > > > > > > On Wednesday 14 November 2007 23:51, Aaron Zeckoski wrote: > > > > > > > Is the 2-way parent/module dependency actually the right way to > > > > > > > link children and parent POMs? This is what we currently have: > > > > > > > > > > > > > > The parent includes definition of a module (or group of > > > > > > > modules) > > > > > > > > like > > > > > > > > > > > so: ... > > > > > > > <groupId>org.sakaiproject</groupId> > > > > > > > <artifactId>base</artifactId> > > > > > > > <packaging>pom</packaging> > > > > > > > ... > > > > > > > <modules> > > > > > > > <module>alias</module> > > > > > > > </modules> > > > > > > > ... > > > > > > > > > > > > > > Then the child defines a parent like so: > > > > > > > ... > > > > > > > <parent> > > > > > > > <artifactId>base</artifactId> > > > > > > > <groupId>org.sakaiproject</groupId> > > > > > > > <version>M2</version> > > > > > > > <relativePath>../pom.xml</relativePath> > > > > > > > </parent> > > > > > > > ... > > > > > > > > > > > > > > As a result, we end up with this 2-way linkage bewteen these > > > > POMs > > > > > > > > > which ends up not being very flexible since all of the POMs > > > > > > > have > > > > to > > > > > > > > > know about each other. > > > > > > > > > > > > > > This seems to be what the docs indicate but I might > > > > misunderstand. > > > > > > Are > > > > > > > > > > > we doing something dumb here? > > > > > > > > > > > > > > Sample parent here: > > > > > > > https://source.sakaiproject.org/contrib/caret/kernel/pom.xmlSam > > > > > > >ple child here: > > > > https://source.sakaiproject.org/contrib/caret/kernel/alias/pom.xml > > > > > > > > > Thanks for the help! > > > > > > > -AZ > > > > > > > > > > > > -- > > > > > > Roland Asmann > > > > > > > > > > > > CFC Informationssysteme Entwicklungsgesellschaft m.b.H > > > > > > Bäckerstrasse 1/2/7 > > > > > > A-1010 Wien > > > > > > FN 266155f, Handelsgericht Wien > > > > > > > > > > > > Tel.: +43/1/513 88 77 - 27 > > > > > > Fax.: +43/1/513 88 62 > > > > > > Email: [EMAIL PROTECTED] > > > > > > Web: www.cfc.at > > > > --------------------------------------------------------------------- > > > > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > -- > > > > Roland Asmann > > > > > > > > CFC Informationssysteme Entwicklungsgesellschaft m.b.H > > > > Bäckerstrasse 1/2/7 > > > > A-1010 Wien > > > > FN 266155f, Handelsgericht Wien > > > > > > > > Tel.: +43/1/513 88 77 - 27 > > > > Fax.: +43/1/513 88 62 > > > > Email: [EMAIL PROTECTED] > > > > Web: www.cfc.at > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > -- > > Roland Asmann > > > > CFC Informationssysteme Entwicklungsgesellschaft m.b.H > > Bäckerstrasse 1/2/7 > > A-1010 Wien > > FN 266155f, Handelsgericht Wien > > > > Tel.: +43/1/513 88 77 - 27 > > Fax.: +43/1/513 88 62 > > Email: [EMAIL PROTECTED] > > Web: www.cfc.at > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] -- Roland Asmann CFC Informationssysteme Entwicklungsgesellschaft m.b.H Bäckerstrasse 1/2/7 A-1010 Wien FN 266155f, Handelsgericht Wien Tel.: +43/1/513 88 77 - 27 Fax.: +43/1/513 88 62 Email: [EMAIL PROTECTED] Web: www.cfc.at --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
