I'm sorry if you didn't understand my previous mail :) Anayway, I attached the POMs in my other mail and as you can see project A do have a parent dependency to the top POM.
/Lars On Thu, 2006-06-22 at 09:41 +0200, Lars Gråmark wrote: > Hej, kontrollera gärna att jag inte skickar nåt jag inte borde skicka. > Det är lätt att missa nåt. > > mvh > Lars > > > > On Wed, 2006-06-21 at 14:47 -0700, Max Cooper wrote: > > I would expect that running install on module A would fail if it really > > had a dependency on the top-level POM, and the top-level POM was not > > available in the local repo. > > > > You can think of your project as having four modules, A B C and Top. The > > dependencies you described are: > > A, B, C depend on Top > > B, C depend on A > > > > Based on this dependency structure, you should have to install project > > Top before any of the others will build individually. > > > > However, based on your reports of the build behavior, it doesn't sound > > like A depends on Top. Does the pom.xml file for A really have a > > <parent> section that refers to Top? > > > > -Max > > > > Lars Gramark wrote: > > > Hello, > > > > > > I get a "Failed to resolve artefact" message when I'm installing one of my > > > sub-projects. > > > Here is the background: > > > We have three projects A, B and C and there is a dependency from B => A > > > and > > > from C => A. > > > Project A do not have any dependencies to any other project but all three > > > projects are organized by a top-POM with the id product. > > > When I install project A onto a clean local repository (mvn install), > > > everything seems fine but when I install project B I get the error message > > > below indicating that it cannot find the top POM snapshot in the > > > repository. > > > > > > [INFO] Failed to resolve artifact. > > > > > > GroupId: mygroupid > > > ArtifactId: product > > > Version: 1.4-SNAPSHOT > > > > > > The error does not occur if I perform the installation from the top-POM > > > but > > > this is not always the preferable way. > > > The current workaround for me is to do a "mvn install -N" from the top > > > level > > > to skip recursing in the sub-project but this seems a bit akward way of > > > solving the problem. > > > Since all sub-project have parent references it seems to me that there is > > > enough information for Maven to compile and install project B or am I > > > missing something? > > > Why does project B require a top-POM in the local repository but not > > > project > > > A? > > > > > > I would really appreciate if someone could explain what going on. > > > > > > Thanks in advance > > > Lars Gramark > > > -- > > > View this message in context: > > > http://www.nabble.com/Top-level-POM-behaviour-t1825699.html#a4980080 > > > Sent from the Maven - Users forum at Nabble.com. > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
