You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Lars Gramark <la...@stickybit.se> on 2006/06/21 20:46:05 UTC
Top-level POM behaviour
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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Top-level POM behaviour
Posted by Lars Gramark <la...@stickybit.se>.
Ok, I think I understand how the modules relate now.
Thanks a lot for your responses.
Best regards
Lars Gramark
--
View this message in context: http://www.nabble.com/Top-level-POM-behaviour-t1825699.html#a5056182
Sent from the Maven - Users forum at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Top-level POM behaviour
Posted by Alexandre Poitras <al...@gmail.com>.
Modules are meant to be built from the top project so you can work on
all of them at the same time. Don't try to build them separatly
because it won't work. If it's not what you want and you prefer
compiling each project separately, you should stick to normal SNAPSHOT
dependencies.
On 6/22/06, Max Cooper <ma...@maxcooper.com> wrote:
> Okay, after looking at your POMs, this is what I think is happening...
>
> 1. When you build project A, maven probably uses the relativePath in the
> parent section to locate the parent POM (rather than looking in the
> local repository).
>
> 2. When you build project B, maven uses the relativePath to find B's
> parent. But during dependency processing, maven looks at project A's POM
> and ignores the relativePath (since maven does not know where A was
> built from, and thus cannot resolve the relative path). Maven must be
> able to locate Top's POM in the repo, but it isn't there, so the build
> fails.
>
> I think that you ultimately must install the parent POM before building
> modules that reference it.
>
>
> If you wish, you can separate the "top" and "parent":
>
> top/
> + parent
> + A
> + B
> + C
>
> "top" will list "parent", A, B, and C as modules. "parent" will be the
> parent for A, B, C, and maybe even "top".
>
> Side note: Perhaps the parent/relativePath element is most useful (and
> least dangerous) in this context, so that "top" can reference "parent".
> If you install "top" it will necessarily also install "parent". This
> eliminates the chance for a confusing missing dependency problem like
> the one that lead to this email thread.
>
> -Max
>
> Lars Gråmark wrote:
> > 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: users-unsubscribe@maven.apache.org
> >>>> For additional commands, e-mail: users-help@maven.apache.org
> >>>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >>> For additional commands, e-mail: users-help@maven.apache.org
> >>>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Top-level POM behaviour
Posted by Max Cooper <ma...@maxcooper.com>.
Okay, after looking at your POMs, this is what I think is happening...
1. When you build project A, maven probably uses the relativePath in the
parent section to locate the parent POM (rather than looking in the
local repository).
2. When you build project B, maven uses the relativePath to find B's
parent. But during dependency processing, maven looks at project A's POM
and ignores the relativePath (since maven does not know where A was
built from, and thus cannot resolve the relative path). Maven must be
able to locate Top's POM in the repo, but it isn't there, so the build
fails.
I think that you ultimately must install the parent POM before building
modules that reference it.
If you wish, you can separate the "top" and "parent":
top/
+ parent
+ A
+ B
+ C
"top" will list "parent", A, B, and C as modules. "parent" will be the
parent for A, B, C, and maybe even "top".
Side note: Perhaps the parent/relativePath element is most useful (and
least dangerous) in this context, so that "top" can reference "parent".
If you install "top" it will necessarily also install "parent". This
eliminates the chance for a confusing missing dependency problem like
the one that lead to this email thread.
-Max
Lars Gråmark wrote:
> 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: users-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Top-level POM behaviour
Posted by Lars Gråmark <la...@stickybit.se>.
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: users-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: users-help@maven.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Top-level POM behaviour
Posted by Lars Gråmark <la...@stickybit.se>.
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: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
Re: Top-level POM behaviour
Posted by Max Cooper <ma...@maxcooper.com>.
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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Top-level POM behaviour
Posted by Yann Le Du <le...@gmail.com>.
Hi Lars,
Can you post your 4 POMs (A + B + C + top) ? - scramble confidential data
first
- Yann
2006/6/21, Lars Gramark <la...@stickybit.se>:
>
>
> 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>