You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Tommy Svensson <to...@natusoft.se> on 2013/11/28 15:32:19 UTC
Maven trying to download pom being built and then fails with what seems to be an imaginary error
My team colleague gets the following error:
_____________________________________________________
mvn clean or mvn help:effective-pom gives the following error:
[INFO] Scanning for projects...
Downloading: https://.../nexus/content/groups/public/.../.../.../xxx-shared/2.0.26-SNAPSHOT/maven-metadata.xml
Downloading: https://.../nexus/content/groups/public/.../.../.../xxx-shared/2.0.26-SNAPSHOT/xxx-shared-2.0.26-SNAPSHOT.pom
[ERROR] The build could not read 1 project -> [Help 1]
[ERROR]
[ERROR] The project xxx.xxx.xxx:xxx-shared-install:2.0.26-SNAPSHOT (/home/xxx/repos/xxx/xxx-shared/install/pom.xml) has 1 error
[ERROR] Non-resolvable parent POM: Could not find artifact xxx.xxx.xxx:xxx-shared:pom:2.0.26-SNAPSHOT in nexus (https://.../nexus/content/groups/public) and 'parent.relativePath <https://.../nexus/content/groups/public%29%20and%20%27parent.relativePath> ' points at wrong local POM @ line 5, column 13 -> [Help 2]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
[ERROR] [Help 2] http://cwiki.apache.org/confluence/display/MAVEN/UnresolvableModelException
_____________________________________________________
The pom it complains about (xxx-shared/install/pom.xml) looks like this:
_____________________________________________________
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<parent>
<groupId>xxx.xxx.xxx</groupId>
<artifactId>xxx-shared</artifactId>
<version>2.0.26-SNAPSHOT</version>
</parent>
<modelVersion>4.0.0</modelVersion>
<artifactId>xxx-shared-install</artifactId>
<packaging>pom</packaging>
<modules>
<module>xxx-base</module>
<module>xxx-mb-base</module>
<module>xxx-mb-default-config</module>
<module>infrastructure</module>
</modules>
</project>
_____________________________________________________
There is no <relativePath> in it, nor in any of the other poms in the whole project structure!
For me it downloads the first file (maven-metadata.xml) and nothing more, and then cleans OK. I can also do "mvn install" without problem.
The
_____________________________________________________
[ERROR] Non-resolvable parent POM: Could not find artifact xxx.xxx.xxxi:xxx-shared:pom:2.0.26-SNAPSHOT in nexus (https://.../nexus/content/groups/public) and 'parent.relativePath <https://.../nexus/content/groups/public%29%20and%20%27parent.relativePath> ' points at wrong local POM @ line 5, column 13 -> [Help 2]
_____________________________________________________
part seems extremely strange to me.
Also note that the actual project being built/cleaned/etc is xxx-shared:2.0.26-SNAPSHOT!! So maven is actually trying to download the pom being built!! I've personally never ever seen that behavior before in my life and I've used maven quite a lot.
Also note that we are building with maven 3.0.x! The biggest difference between me and my colleague is that I'm running on SUSE and she is running on Ubuntu, but that shouldn't make any difference.
Any suggestions are appreciated since I'm out of ideas myself.
Best Regards,
Tommy Svensson
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven trying to download pom being built and then fails with what seems to be an imaginary error
Posted by Tommy Svensson <to...@natusoft.se>.
I found what you are referring to:
... to the "install" module ...
but in this case I have a module actually called "install" :-). And qouting names I think is valid too, also for clarity.
But I do understand the possible confusion.
/Tommy
29 nov 2013 kl. 10:26 skrev Stephen Connolly <st...@gmail.com>:
> if you'd had the "mvn " in the quotes too then I wouldn't have made the
> assumption... or if you'd been talking about the "install"ed pom... but
> people employing some of the Donny-Don't style hacks that my blog post aims
> to discourage typically have a special pom for installing these 3rd party
> jars and for some reason they almost always refer to it as their "install"
> pom.... and then they have problems with the build failing to download
> artifacts... so you can see why I might make my assumption ;-)
>
>
> On 29 November 2013 08:04, Tommy Svensson <to...@natusoft.se> wrote:
>
>> OK, now I understand. No that is not the case here. I'm one of the few
>> then I guess :-). I usually use quotes around commands like "mvn install"
>> to make clear exactly what the command is and distinguish it from the rest
>> of the text. If the command I'm showing is longer I put it on a separate
>> line and indented, but small things go into quotes. Maybe I should use
>> single quotes instead :-).
>>
>> /Tommy
>>
>> 28 nov 2013 kl. 18:58 skrev Stephen Connolly <
>> stephen.alan.connolly@gmail.com>:
>>
>>> Sounded like you were using a pom to "install" 3rd party jars into the
>>> local repo for other modules to use... I ack that I could be wildly off
>>> base... but when we see people talking about their "install" pom and
>>> putting "install" in quotes 9 times out of 10 they are trying to hack
>>> installing .jar files into the local repo... you may be the 1 time out of
>>> 10 that isn't ;-)
>>>
>>>
>>> On 28 November 2013 17:19, Tommy Svensson <to...@natusoft.se> wrote:
>>>
>>>>
>>>> 28 nov 2013 kl. 18:10 skrev Stephen Connolly <
>>>> stephen.alan.connolly@gmail.com>:
>>>>
>>>>> Hmmm I suspect you may not have read this post:
>>>>>
>>>>
>> http://developer-blog.cloudbees.com/2013/03/playing-trade-offs-with-maven.html
>>>>
>>>> No, I had not. After looking at it I have no idea what you are trying to
>>>> say with it.
>>>>
>>>>>
>>>>> (Trigger for suspicion is people referring to an "install" pom... esp
>>>> when
>>>>> they put install in quotes)
>>>>
>>>> I'm failing here too.
>>>>
>>>> /Tommy
>>>>
>>>>>
>>>>>
>>>>> On 28 November 2013 17:04, Tommy Svensson <to...@natusoft.se> wrote:
>>>>>
>>>>>> I did remove my local repository files (~/.m2/repository/...) and did
>> an
>>>>>> "mvn install" and got this exact problem myself!
>>>>>>
>>>>>> I'm however completely failing to understand why. I tried to add
>>>>>> "<relativePath>..</relativePath> to the "install" module but that made
>>>> no
>>>>>> difference and since ".." is the one and only relative path to the
>>>> parent
>>>>>> it should make no difference, so I guess that was correct :-). And why
>>>> does
>>>>>> it start with trying to download the pom of the project I'm building.
>>>> It is
>>>>>> available right there in the catalog I'm standing in when running "mvn
>>>>>> install". It should be downloading its parent pom, which it does and
>>>>>> succeeds with, but it should not be trying to download itself since it
>>>> is
>>>>>> already running itself, and thus already have itself.
>>>>>>
>>>>>> Do note that the top parent (the one being successfully downloaded)
>> does
>>>>>> not contain any modules! It only provides plugins, properties, etc. It
>>>> has
>>>>>> no knowledge of its children.
>>>>>>
>>>>>> Regards,
>>>>>> Tommy Svensson
>>>>>>
>>>>>>
>>>>>> 28 nov 2013 kl. 17:33 skrev Tommy Svensson <to...@natusoft.se>:
>>>>>>
>>>>>>>
>>>>>>> 28 nov 2013 kl. 15:39 skrev Nick Stolwijk <ni...@gmail.com>:
>>>>>>>
>>>>>>>> Probably you have the xxx-shared artifact already in your local
>>>>>> repository
>>>>>>>> from an earlier invocation, so it won't get looked up in Nexus,
>> while
>>>>>> your
>>>>>>>> colleague doesn't.
>>>>>>>>
>>>>>>>> I think your parent part of the pom should look something like this:
>>>>>>>>
>>>>>>>> <parent>
>>>>>>>> <groupId>xxx.xxx.xxx</groupId>
>>>>>>>> <artifactId>xxx-shared</artifactId>
>>>>>>>> <version>2.0.26-SNAPSHOT</version>
>>>>>>>> <relativePath>../xxx-shared/pom.xml</relativePath>
>>>>>>>> </parent>
>>>>>>>
>>>>>>> It is *at* this parent that the "mvn clean" is done! The one failing
>> is
>>>>>> a module of this and is residing with a correct relative path to this
>>>>>> parent.
>>>>>>>
>>>>>>> But it is correct that only I have this artifact in my local
>> repository
>>>>>> since my colleague are failing to build this due to this problem.
>>>>>>>
>>>>>>>>
>>>>>>>> Try to empty your local repository (~/.m2/repository/xxx/xxx/xxx/
>> and
>>>>>>>> rebuild. I guess without setting the relativePath you will see the
>>>> same
>>>>>>>> error as your colleague.
>>>>>>>
>>>>>>> The relative path is ".." and should thus be correct. But "cleaning"
>> my
>>>>>> ~/.m2/repository/... artifacts is probably a good test to do anyhow.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Tommy Svensson
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Hth,
>>>>>>>>
>>>>>>>> Nick Stolwijk
>>>>>>>> On Thu, Nov 28, 2013 at 3:32 PM, Tommy Svensson <to...@natusoft.se>
>>>>>> wrote:
>>>>>>>>
>>>>>>>>> <parent>
>>>>>>>>> <groupId>xxx.xxx.xxx</groupId>
>>>>>>>>> <artifactId>xxx-shared</artifactId>
>>>>>>>>> <version>2.0.26-SNAPSHOT</version>
>>>>>>>>> </parent>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Nick Stolwijk
>>>>>>>>
>>>>>>>> ~~~ Try to leave this world a little better than you found it and,
>>>> when
>>>>>>>> your turn comes to die, you can die happy in feeling that at any
>> rate
>>>>>> you
>>>>>>>> have not wasted your time but have done your best ~~~
>>>>>>>>
>>>>>>>> Lord Baden-Powell
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> 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: Maven trying to download pom being built and then fails with what
seems to be an imaginary error
Posted by Stephen Connolly <st...@gmail.com>.
if you'd had the "mvn " in the quotes too then I wouldn't have made the
assumption... or if you'd been talking about the "install"ed pom... but
people employing some of the Donny-Don't style hacks that my blog post aims
to discourage typically have a special pom for installing these 3rd party
jars and for some reason they almost always refer to it as their "install"
pom.... and then they have problems with the build failing to download
artifacts... so you can see why I might make my assumption ;-)
On 29 November 2013 08:04, Tommy Svensson <to...@natusoft.se> wrote:
> OK, now I understand. No that is not the case here. I'm one of the few
> then I guess :-). I usually use quotes around commands like "mvn install"
> to make clear exactly what the command is and distinguish it from the rest
> of the text. If the command I'm showing is longer I put it on a separate
> line and indented, but small things go into quotes. Maybe I should use
> single quotes instead :-).
>
> /Tommy
>
> 28 nov 2013 kl. 18:58 skrev Stephen Connolly <
> stephen.alan.connolly@gmail.com>:
>
> > Sounded like you were using a pom to "install" 3rd party jars into the
> > local repo for other modules to use... I ack that I could be wildly off
> > base... but when we see people talking about their "install" pom and
> > putting "install" in quotes 9 times out of 10 they are trying to hack
> > installing .jar files into the local repo... you may be the 1 time out of
> > 10 that isn't ;-)
> >
> >
> > On 28 November 2013 17:19, Tommy Svensson <to...@natusoft.se> wrote:
> >
> >>
> >> 28 nov 2013 kl. 18:10 skrev Stephen Connolly <
> >> stephen.alan.connolly@gmail.com>:
> >>
> >>> Hmmm I suspect you may not have read this post:
> >>>
> >>
> http://developer-blog.cloudbees.com/2013/03/playing-trade-offs-with-maven.html
> >>
> >> No, I had not. After looking at it I have no idea what you are trying to
> >> say with it.
> >>
> >>>
> >>> (Trigger for suspicion is people referring to an "install" pom... esp
> >> when
> >>> they put install in quotes)
> >>
> >> I'm failing here too.
> >>
> >> /Tommy
> >>
> >>>
> >>>
> >>> On 28 November 2013 17:04, Tommy Svensson <to...@natusoft.se> wrote:
> >>>
> >>>> I did remove my local repository files (~/.m2/repository/...) and did
> an
> >>>> "mvn install" and got this exact problem myself!
> >>>>
> >>>> I'm however completely failing to understand why. I tried to add
> >>>> "<relativePath>..</relativePath> to the "install" module but that made
> >> no
> >>>> difference and since ".." is the one and only relative path to the
> >> parent
> >>>> it should make no difference, so I guess that was correct :-). And why
> >> does
> >>>> it start with trying to download the pom of the project I'm building.
> >> It is
> >>>> available right there in the catalog I'm standing in when running "mvn
> >>>> install". It should be downloading its parent pom, which it does and
> >>>> succeeds with, but it should not be trying to download itself since it
> >> is
> >>>> already running itself, and thus already have itself.
> >>>>
> >>>> Do note that the top parent (the one being successfully downloaded)
> does
> >>>> not contain any modules! It only provides plugins, properties, etc. It
> >> has
> >>>> no knowledge of its children.
> >>>>
> >>>> Regards,
> >>>> Tommy Svensson
> >>>>
> >>>>
> >>>> 28 nov 2013 kl. 17:33 skrev Tommy Svensson <to...@natusoft.se>:
> >>>>
> >>>>>
> >>>>> 28 nov 2013 kl. 15:39 skrev Nick Stolwijk <ni...@gmail.com>:
> >>>>>
> >>>>>> Probably you have the xxx-shared artifact already in your local
> >>>> repository
> >>>>>> from an earlier invocation, so it won't get looked up in Nexus,
> while
> >>>> your
> >>>>>> colleague doesn't.
> >>>>>>
> >>>>>> I think your parent part of the pom should look something like this:
> >>>>>>
> >>>>>> <parent>
> >>>>>> <groupId>xxx.xxx.xxx</groupId>
> >>>>>> <artifactId>xxx-shared</artifactId>
> >>>>>> <version>2.0.26-SNAPSHOT</version>
> >>>>>> <relativePath>../xxx-shared/pom.xml</relativePath>
> >>>>>> </parent>
> >>>>>
> >>>>> It is *at* this parent that the "mvn clean" is done! The one failing
> is
> >>>> a module of this and is residing with a correct relative path to this
> >>>> parent.
> >>>>>
> >>>>> But it is correct that only I have this artifact in my local
> repository
> >>>> since my colleague are failing to build this due to this problem.
> >>>>>
> >>>>>>
> >>>>>> Try to empty your local repository (~/.m2/repository/xxx/xxx/xxx/
> and
> >>>>>> rebuild. I guess without setting the relativePath you will see the
> >> same
> >>>>>> error as your colleague.
> >>>>>
> >>>>> The relative path is ".." and should thus be correct. But "cleaning"
> my
> >>>> ~/.m2/repository/... artifacts is probably a good test to do anyhow.
> >>>>>
> >>>>> Thanks,
> >>>>> Tommy Svensson
> >>>>>
> >>>>>
> >>>>>>
> >>>>>> Hth,
> >>>>>>
> >>>>>> Nick Stolwijk
> >>>>>> On Thu, Nov 28, 2013 at 3:32 PM, Tommy Svensson <to...@natusoft.se>
> >>>> wrote:
> >>>>>>
> >>>>>>> <parent>
> >>>>>>> <groupId>xxx.xxx.xxx</groupId>
> >>>>>>> <artifactId>xxx-shared</artifactId>
> >>>>>>> <version>2.0.26-SNAPSHOT</version>
> >>>>>>> </parent>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> Nick Stolwijk
> >>>>>>
> >>>>>> ~~~ Try to leave this world a little better than you found it and,
> >> when
> >>>>>> your turn comes to die, you can die happy in feeling that at any
> rate
> >>>> you
> >>>>>> have not wasted your time but have done your best ~~~
> >>>>>>
> >>>>>> Lord Baden-Powell
> >>>>>
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> 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: Maven trying to download pom being built and then fails with what seems to be an imaginary error
Posted by Tommy Svensson <to...@natusoft.se>.
OK, now I understand. No that is not the case here. I'm one of the few then I guess :-). I usually use quotes around commands like "mvn install" to make clear exactly what the command is and distinguish it from the rest of the text. If the command I'm showing is longer I put it on a separate line and indented, but small things go into quotes. Maybe I should use single quotes instead :-).
/Tommy
28 nov 2013 kl. 18:58 skrev Stephen Connolly <st...@gmail.com>:
> Sounded like you were using a pom to "install" 3rd party jars into the
> local repo for other modules to use... I ack that I could be wildly off
> base... but when we see people talking about their "install" pom and
> putting "install" in quotes 9 times out of 10 they are trying to hack
> installing .jar files into the local repo... you may be the 1 time out of
> 10 that isn't ;-)
>
>
> On 28 November 2013 17:19, Tommy Svensson <to...@natusoft.se> wrote:
>
>>
>> 28 nov 2013 kl. 18:10 skrev Stephen Connolly <
>> stephen.alan.connolly@gmail.com>:
>>
>>> Hmmm I suspect you may not have read this post:
>>>
>> http://developer-blog.cloudbees.com/2013/03/playing-trade-offs-with-maven.html
>>
>> No, I had not. After looking at it I have no idea what you are trying to
>> say with it.
>>
>>>
>>> (Trigger for suspicion is people referring to an "install" pom... esp
>> when
>>> they put install in quotes)
>>
>> I'm failing here too.
>>
>> /Tommy
>>
>>>
>>>
>>> On 28 November 2013 17:04, Tommy Svensson <to...@natusoft.se> wrote:
>>>
>>>> I did remove my local repository files (~/.m2/repository/...) and did an
>>>> "mvn install" and got this exact problem myself!
>>>>
>>>> I'm however completely failing to understand why. I tried to add
>>>> "<relativePath>..</relativePath> to the "install" module but that made
>> no
>>>> difference and since ".." is the one and only relative path to the
>> parent
>>>> it should make no difference, so I guess that was correct :-). And why
>> does
>>>> it start with trying to download the pom of the project I'm building.
>> It is
>>>> available right there in the catalog I'm standing in when running "mvn
>>>> install". It should be downloading its parent pom, which it does and
>>>> succeeds with, but it should not be trying to download itself since it
>> is
>>>> already running itself, and thus already have itself.
>>>>
>>>> Do note that the top parent (the one being successfully downloaded) does
>>>> not contain any modules! It only provides plugins, properties, etc. It
>> has
>>>> no knowledge of its children.
>>>>
>>>> Regards,
>>>> Tommy Svensson
>>>>
>>>>
>>>> 28 nov 2013 kl. 17:33 skrev Tommy Svensson <to...@natusoft.se>:
>>>>
>>>>>
>>>>> 28 nov 2013 kl. 15:39 skrev Nick Stolwijk <ni...@gmail.com>:
>>>>>
>>>>>> Probably you have the xxx-shared artifact already in your local
>>>> repository
>>>>>> from an earlier invocation, so it won't get looked up in Nexus, while
>>>> your
>>>>>> colleague doesn't.
>>>>>>
>>>>>> I think your parent part of the pom should look something like this:
>>>>>>
>>>>>> <parent>
>>>>>> <groupId>xxx.xxx.xxx</groupId>
>>>>>> <artifactId>xxx-shared</artifactId>
>>>>>> <version>2.0.26-SNAPSHOT</version>
>>>>>> <relativePath>../xxx-shared/pom.xml</relativePath>
>>>>>> </parent>
>>>>>
>>>>> It is *at* this parent that the "mvn clean" is done! The one failing is
>>>> a module of this and is residing with a correct relative path to this
>>>> parent.
>>>>>
>>>>> But it is correct that only I have this artifact in my local repository
>>>> since my colleague are failing to build this due to this problem.
>>>>>
>>>>>>
>>>>>> Try to empty your local repository (~/.m2/repository/xxx/xxx/xxx/ and
>>>>>> rebuild. I guess without setting the relativePath you will see the
>> same
>>>>>> error as your colleague.
>>>>>
>>>>> The relative path is ".." and should thus be correct. But "cleaning" my
>>>> ~/.m2/repository/... artifacts is probably a good test to do anyhow.
>>>>>
>>>>> Thanks,
>>>>> Tommy Svensson
>>>>>
>>>>>
>>>>>>
>>>>>> Hth,
>>>>>>
>>>>>> Nick Stolwijk
>>>>>> On Thu, Nov 28, 2013 at 3:32 PM, Tommy Svensson <to...@natusoft.se>
>>>> wrote:
>>>>>>
>>>>>>> <parent>
>>>>>>> <groupId>xxx.xxx.xxx</groupId>
>>>>>>> <artifactId>xxx-shared</artifactId>
>>>>>>> <version>2.0.26-SNAPSHOT</version>
>>>>>>> </parent>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Nick Stolwijk
>>>>>>
>>>>>> ~~~ Try to leave this world a little better than you found it and,
>> when
>>>>>> your turn comes to die, you can die happy in feeling that at any rate
>>>> you
>>>>>> have not wasted your time but have done your best ~~~
>>>>>>
>>>>>> Lord Baden-Powell
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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: Maven trying to download pom being built and then fails with what
seems to be an imaginary error
Posted by Stephen Connolly <st...@gmail.com>.
Sounded like you were using a pom to "install" 3rd party jars into the
local repo for other modules to use... I ack that I could be wildly off
base... but when we see people talking about their "install" pom and
putting "install" in quotes 9 times out of 10 they are trying to hack
installing .jar files into the local repo... you may be the 1 time out of
10 that isn't ;-)
On 28 November 2013 17:19, Tommy Svensson <to...@natusoft.se> wrote:
>
> 28 nov 2013 kl. 18:10 skrev Stephen Connolly <
> stephen.alan.connolly@gmail.com>:
>
> > Hmmm I suspect you may not have read this post:
> >
> http://developer-blog.cloudbees.com/2013/03/playing-trade-offs-with-maven.html
>
> No, I had not. After looking at it I have no idea what you are trying to
> say with it.
>
> >
> > (Trigger for suspicion is people referring to an "install" pom... esp
> when
> > they put install in quotes)
>
> I'm failing here too.
>
> /Tommy
>
> >
> >
> > On 28 November 2013 17:04, Tommy Svensson <to...@natusoft.se> wrote:
> >
> >> I did remove my local repository files (~/.m2/repository/...) and did an
> >> "mvn install" and got this exact problem myself!
> >>
> >> I'm however completely failing to understand why. I tried to add
> >> "<relativePath>..</relativePath> to the "install" module but that made
> no
> >> difference and since ".." is the one and only relative path to the
> parent
> >> it should make no difference, so I guess that was correct :-). And why
> does
> >> it start with trying to download the pom of the project I'm building.
> It is
> >> available right there in the catalog I'm standing in when running "mvn
> >> install". It should be downloading its parent pom, which it does and
> >> succeeds with, but it should not be trying to download itself since it
> is
> >> already running itself, and thus already have itself.
> >>
> >> Do note that the top parent (the one being successfully downloaded) does
> >> not contain any modules! It only provides plugins, properties, etc. It
> has
> >> no knowledge of its children.
> >>
> >> Regards,
> >> Tommy Svensson
> >>
> >>
> >> 28 nov 2013 kl. 17:33 skrev Tommy Svensson <to...@natusoft.se>:
> >>
> >>>
> >>> 28 nov 2013 kl. 15:39 skrev Nick Stolwijk <ni...@gmail.com>:
> >>>
> >>>> Probably you have the xxx-shared artifact already in your local
> >> repository
> >>>> from an earlier invocation, so it won't get looked up in Nexus, while
> >> your
> >>>> colleague doesn't.
> >>>>
> >>>> I think your parent part of the pom should look something like this:
> >>>>
> >>>> <parent>
> >>>> <groupId>xxx.xxx.xxx</groupId>
> >>>> <artifactId>xxx-shared</artifactId>
> >>>> <version>2.0.26-SNAPSHOT</version>
> >>>> <relativePath>../xxx-shared/pom.xml</relativePath>
> >>>> </parent>
> >>>
> >>> It is *at* this parent that the "mvn clean" is done! The one failing is
> >> a module of this and is residing with a correct relative path to this
> >> parent.
> >>>
> >>> But it is correct that only I have this artifact in my local repository
> >> since my colleague are failing to build this due to this problem.
> >>>
> >>>>
> >>>> Try to empty your local repository (~/.m2/repository/xxx/xxx/xxx/ and
> >>>> rebuild. I guess without setting the relativePath you will see the
> same
> >>>> error as your colleague.
> >>>
> >>> The relative path is ".." and should thus be correct. But "cleaning" my
> >> ~/.m2/repository/... artifacts is probably a good test to do anyhow.
> >>>
> >>> Thanks,
> >>> Tommy Svensson
> >>>
> >>>
> >>>>
> >>>> Hth,
> >>>>
> >>>> Nick Stolwijk
> >>>> On Thu, Nov 28, 2013 at 3:32 PM, Tommy Svensson <to...@natusoft.se>
> >> wrote:
> >>>>
> >>>>> <parent>
> >>>>> <groupId>xxx.xxx.xxx</groupId>
> >>>>> <artifactId>xxx-shared</artifactId>
> >>>>> <version>2.0.26-SNAPSHOT</version>
> >>>>> </parent>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> Nick Stolwijk
> >>>>
> >>>> ~~~ Try to leave this world a little better than you found it and,
> when
> >>>> your turn comes to die, you can die happy in feeling that at any rate
> >> you
> >>>> have not wasted your time but have done your best ~~~
> >>>>
> >>>> Lord Baden-Powell
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> 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: Maven trying to download pom being built and then fails with what seems to be an imaginary error
Posted by Tommy Svensson <to...@natusoft.se>.
28 nov 2013 kl. 18:10 skrev Stephen Connolly <st...@gmail.com>:
> Hmmm I suspect you may not have read this post:
> http://developer-blog.cloudbees.com/2013/03/playing-trade-offs-with-maven.html
No, I had not. After looking at it I have no idea what you are trying to say with it.
>
> (Trigger for suspicion is people referring to an "install" pom... esp when
> they put install in quotes)
I'm failing here too.
/Tommy
>
>
> On 28 November 2013 17:04, Tommy Svensson <to...@natusoft.se> wrote:
>
>> I did remove my local repository files (~/.m2/repository/...) and did an
>> "mvn install" and got this exact problem myself!
>>
>> I'm however completely failing to understand why. I tried to add
>> "<relativePath>..</relativePath> to the "install" module but that made no
>> difference and since ".." is the one and only relative path to the parent
>> it should make no difference, so I guess that was correct :-). And why does
>> it start with trying to download the pom of the project I'm building. It is
>> available right there in the catalog I'm standing in when running "mvn
>> install". It should be downloading its parent pom, which it does and
>> succeeds with, but it should not be trying to download itself since it is
>> already running itself, and thus already have itself.
>>
>> Do note that the top parent (the one being successfully downloaded) does
>> not contain any modules! It only provides plugins, properties, etc. It has
>> no knowledge of its children.
>>
>> Regards,
>> Tommy Svensson
>>
>>
>> 28 nov 2013 kl. 17:33 skrev Tommy Svensson <to...@natusoft.se>:
>>
>>>
>>> 28 nov 2013 kl. 15:39 skrev Nick Stolwijk <ni...@gmail.com>:
>>>
>>>> Probably you have the xxx-shared artifact already in your local
>> repository
>>>> from an earlier invocation, so it won't get looked up in Nexus, while
>> your
>>>> colleague doesn't.
>>>>
>>>> I think your parent part of the pom should look something like this:
>>>>
>>>> <parent>
>>>> <groupId>xxx.xxx.xxx</groupId>
>>>> <artifactId>xxx-shared</artifactId>
>>>> <version>2.0.26-SNAPSHOT</version>
>>>> <relativePath>../xxx-shared/pom.xml</relativePath>
>>>> </parent>
>>>
>>> It is *at* this parent that the "mvn clean" is done! The one failing is
>> a module of this and is residing with a correct relative path to this
>> parent.
>>>
>>> But it is correct that only I have this artifact in my local repository
>> since my colleague are failing to build this due to this problem.
>>>
>>>>
>>>> Try to empty your local repository (~/.m2/repository/xxx/xxx/xxx/ and
>>>> rebuild. I guess without setting the relativePath you will see the same
>>>> error as your colleague.
>>>
>>> The relative path is ".." and should thus be correct. But "cleaning" my
>> ~/.m2/repository/... artifacts is probably a good test to do anyhow.
>>>
>>> Thanks,
>>> Tommy Svensson
>>>
>>>
>>>>
>>>> Hth,
>>>>
>>>> Nick Stolwijk
>>>> On Thu, Nov 28, 2013 at 3:32 PM, Tommy Svensson <to...@natusoft.se>
>> wrote:
>>>>
>>>>> <parent>
>>>>> <groupId>xxx.xxx.xxx</groupId>
>>>>> <artifactId>xxx-shared</artifactId>
>>>>> <version>2.0.26-SNAPSHOT</version>
>>>>> </parent>
>>>>>
>>>>
>>>>
>>>>
>>>> Nick Stolwijk
>>>>
>>>> ~~~ Try to leave this world a little better than you found it and, when
>>>> your turn comes to die, you can die happy in feeling that at any rate
>> you
>>>> have not wasted your time but have done your best ~~~
>>>>
>>>> Lord Baden-Powell
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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: Maven trying to download pom being built and then fails with what
seems to be an imaginary error
Posted by Stephen Connolly <st...@gmail.com>.
Hmmm I suspect you may not have read this post:
http://developer-blog.cloudbees.com/2013/03/playing-trade-offs-with-maven.html
(Trigger for suspicion is people referring to an "install" pom... esp when
they put install in quotes)
On 28 November 2013 17:04, Tommy Svensson <to...@natusoft.se> wrote:
> I did remove my local repository files (~/.m2/repository/...) and did an
> "mvn install" and got this exact problem myself!
>
> I'm however completely failing to understand why. I tried to add
> "<relativePath>..</relativePath> to the "install" module but that made no
> difference and since ".." is the one and only relative path to the parent
> it should make no difference, so I guess that was correct :-). And why does
> it start with trying to download the pom of the project I'm building. It is
> available right there in the catalog I'm standing in when running "mvn
> install". It should be downloading its parent pom, which it does and
> succeeds with, but it should not be trying to download itself since it is
> already running itself, and thus already have itself.
>
> Do note that the top parent (the one being successfully downloaded) does
> not contain any modules! It only provides plugins, properties, etc. It has
> no knowledge of its children.
>
> Regards,
> Tommy Svensson
>
>
> 28 nov 2013 kl. 17:33 skrev Tommy Svensson <to...@natusoft.se>:
>
> >
> > 28 nov 2013 kl. 15:39 skrev Nick Stolwijk <ni...@gmail.com>:
> >
> >> Probably you have the xxx-shared artifact already in your local
> repository
> >> from an earlier invocation, so it won't get looked up in Nexus, while
> your
> >> colleague doesn't.
> >>
> >> I think your parent part of the pom should look something like this:
> >>
> >> <parent>
> >> <groupId>xxx.xxx.xxx</groupId>
> >> <artifactId>xxx-shared</artifactId>
> >> <version>2.0.26-SNAPSHOT</version>
> >> <relativePath>../xxx-shared/pom.xml</relativePath>
> >> </parent>
> >
> > It is *at* this parent that the "mvn clean" is done! The one failing is
> a module of this and is residing with a correct relative path to this
> parent.
> >
> > But it is correct that only I have this artifact in my local repository
> since my colleague are failing to build this due to this problem.
> >
> >>
> >> Try to empty your local repository (~/.m2/repository/xxx/xxx/xxx/ and
> >> rebuild. I guess without setting the relativePath you will see the same
> >> error as your colleague.
> >
> > The relative path is ".." and should thus be correct. But "cleaning" my
> ~/.m2/repository/... artifacts is probably a good test to do anyhow.
> >
> > Thanks,
> > Tommy Svensson
> >
> >
> >>
> >> Hth,
> >>
> >> Nick Stolwijk
> >> On Thu, Nov 28, 2013 at 3:32 PM, Tommy Svensson <to...@natusoft.se>
> wrote:
> >>
> >>> <parent>
> >>> <groupId>xxx.xxx.xxx</groupId>
> >>> <artifactId>xxx-shared</artifactId>
> >>> <version>2.0.26-SNAPSHOT</version>
> >>> </parent>
> >>>
> >>
> >>
> >>
> >> Nick Stolwijk
> >>
> >> ~~~ Try to leave this world a little better than you found it and, when
> >> your turn comes to die, you can die happy in feeling that at any rate
> you
> >> have not wasted your time but have done your best ~~~
> >>
> >> Lord Baden-Powell
> >
> >
> > ---------------------------------------------------------------------
> > 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: Maven trying to download pom being built and then fails with what seems to be an imaginary error
Posted by Tommy Svensson <to...@natusoft.se>.
I have found the problem and I'm posting it here just to punish myself!
The reason it was trying to download xxx-share:2.0.26-SNAPSHOT is that I was building xxx-share:3.3.2-SNAPSHOT! The last pull gave me a new version and I have added modules that are not available to others yet that still refered to xxx-share:2.0.26-SNAPSHOT. So it was not trying to download itself. It was trying to download an older version of itself.
This should of course been the first thing to check for, and the obvious answer to the problem! Damn it!
/Tommy
29 nov 2013 kl. 09:32 skrev Tommy Svensson <to...@natusoft.se>:
> I think I know where this problem comes from. There is a limitation to maven that sometimes get misused. In this specific case there is a super parent containing a lot of common stuff of which only a few need, and some needs certain parts of it and some needs other parts. I have seen other strange problems when inheriting from this parent (like producing unreadable artifacts!) that have simply gone away when I remove the inheritance to it, which I only can do where there really are no dependencies on it or in the parent chain up to it.
>
> But I understand that people do this since the alternative is to duplicate things over and over where needed. There are however a smart guy that have done something to help solve this situation:
>
> https://github.com/maoo/maven-tiles
>
> I've used it in other projects and it works quite nice. It allows you to break out common functionality into separate artifacts delivering only a pom. Then these tile poms are included where needed, and you can create several tiles for different things and in each case include those you need. This removes the need for everything and more in a super parent for all.
>
> /Tommy
>
> 28 nov 2013 kl. 18:12 skrev Tommy Svensson <to...@natusoft.se>:
>
>> Actually, if maven is failing to see the project being built (itself) it would explain both that it tries to download its own pom and that the first module child fails to see the parent.
>>
>> But what would make it fail to se itself ? It is a valid pom and it is called pom.xml.
>>
>> Regards,
>> Tommy Svensson
>>
>>
>> 28 nov 2013 kl. 18:04 skrev Tommy Svensson <to...@natusoft.se>:
>>
>>> I did remove my local repository files (~/.m2/repository/...) and did an "mvn install" and got this exact problem myself!
>>>
>>> I'm however completely failing to understand why. I tried to add "<relativePath>..</relativePath> to the "install" module but that made no difference and since ".." is the one and only relative path to the parent it should make no difference, so I guess that was correct :-). And why does it start with trying to download the pom of the project I'm building. It is available right there in the catalog I'm standing in when running "mvn install". It should be downloading its parent pom, which it does and succeeds with, but it should not be trying to download itself since it is already running itself, and thus already have itself.
>>>
>>> Do note that the top parent (the one being successfully downloaded) does not contain any modules! It only provides plugins, properties, etc. It has no knowledge of its children.
>>>
>>> Regards,
>>> Tommy Svensson
>>>
>>>
>>> 28 nov 2013 kl. 17:33 skrev Tommy Svensson <to...@natusoft.se>:
>>>
>>>>
>>>> 28 nov 2013 kl. 15:39 skrev Nick Stolwijk <ni...@gmail.com>:
>>>>
>>>>> Probably you have the xxx-shared artifact already in your local repository
>>>>> from an earlier invocation, so it won't get looked up in Nexus, while your
>>>>> colleague doesn't.
>>>>>
>>>>> I think your parent part of the pom should look something like this:
>>>>>
>>>>> <parent>
>>>>> <groupId>xxx.xxx.xxx</groupId>
>>>>> <artifactId>xxx-shared</artifactId>
>>>>> <version>2.0.26-SNAPSHOT</version>
>>>>> <relativePath>../xxx-shared/pom.xml</relativePath>
>>>>> </parent>
>>>>
>>>> It is *at* this parent that the "mvn clean" is done! The one failing is a module of this and is residing with a correct relative path to this parent.
>>>>
>>>> But it is correct that only I have this artifact in my local repository since my colleague are failing to build this due to this problem.
>>>>
>>>>>
>>>>> Try to empty your local repository (~/.m2/repository/xxx/xxx/xxx/ and
>>>>> rebuild. I guess without setting the relativePath you will see the same
>>>>> error as your colleague.
>>>>
>>>> The relative path is ".." and should thus be correct. But "cleaning" my ~/.m2/repository/... artifacts is probably a good test to do anyhow.
>>>>
>>>> Thanks,
>>>> Tommy Svensson
>>>>
>>>>
>>>>>
>>>>> Hth,
>>>>>
>>>>> Nick Stolwijk
>>>>> On Thu, Nov 28, 2013 at 3:32 PM, Tommy Svensson <to...@natusoft.se> wrote:
>>>>>
>>>>>> <parent>
>>>>>> <groupId>xxx.xxx.xxx</groupId>
>>>>>> <artifactId>xxx-shared</artifactId>
>>>>>> <version>2.0.26-SNAPSHOT</version>
>>>>>> </parent>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Nick Stolwijk
>>>>>
>>>>> ~~~ Try to leave this world a little better than you found it and, when
>>>>> your turn comes to die, you can die happy in feeling that at any rate you
>>>>> have not wasted your time but have done your best ~~~
>>>>>
>>>>> Lord Baden-Powell
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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: Maven trying to download pom being built and then fails with what seems to be an imaginary error
Posted by Tommy Svensson <to...@natusoft.se>.
I think I know where this problem comes from. There is a limitation to maven that sometimes get misused. In this specific case there is a super parent containing a lot of common stuff of which only a few need, and some needs certain parts of it and some needs other parts. I have seen other strange problems when inheriting from this parent (like producing unreadable artifacts!) that have simply gone away when I remove the inheritance to it, which I only can do where there really are no dependencies on it or in the parent chain up to it.
But I understand that people do this since the alternative is to duplicate things over and over where needed. There are however a smart guy that have done something to help solve this situation:
https://github.com/maoo/maven-tiles
I've used it in other projects and it works quite nice. It allows you to break out common functionality into separate artifacts delivering only a pom. Then these tile poms are included where needed, and you can create several tiles for different things and in each case include those you need. This removes the need for everything and more in a super parent for all.
/Tommy
28 nov 2013 kl. 18:12 skrev Tommy Svensson <to...@natusoft.se>:
> Actually, if maven is failing to see the project being built (itself) it would explain both that it tries to download its own pom and that the first module child fails to see the parent.
>
> But what would make it fail to se itself ? It is a valid pom and it is called pom.xml.
>
> Regards,
> Tommy Svensson
>
>
> 28 nov 2013 kl. 18:04 skrev Tommy Svensson <to...@natusoft.se>:
>
>> I did remove my local repository files (~/.m2/repository/...) and did an "mvn install" and got this exact problem myself!
>>
>> I'm however completely failing to understand why. I tried to add "<relativePath>..</relativePath> to the "install" module but that made no difference and since ".." is the one and only relative path to the parent it should make no difference, so I guess that was correct :-). And why does it start with trying to download the pom of the project I'm building. It is available right there in the catalog I'm standing in when running "mvn install". It should be downloading its parent pom, which it does and succeeds with, but it should not be trying to download itself since it is already running itself, and thus already have itself.
>>
>> Do note that the top parent (the one being successfully downloaded) does not contain any modules! It only provides plugins, properties, etc. It has no knowledge of its children.
>>
>> Regards,
>> Tommy Svensson
>>
>>
>> 28 nov 2013 kl. 17:33 skrev Tommy Svensson <to...@natusoft.se>:
>>
>>>
>>> 28 nov 2013 kl. 15:39 skrev Nick Stolwijk <ni...@gmail.com>:
>>>
>>>> Probably you have the xxx-shared artifact already in your local repository
>>>> from an earlier invocation, so it won't get looked up in Nexus, while your
>>>> colleague doesn't.
>>>>
>>>> I think your parent part of the pom should look something like this:
>>>>
>>>> <parent>
>>>> <groupId>xxx.xxx.xxx</groupId>
>>>> <artifactId>xxx-shared</artifactId>
>>>> <version>2.0.26-SNAPSHOT</version>
>>>> <relativePath>../xxx-shared/pom.xml</relativePath>
>>>> </parent>
>>>
>>> It is *at* this parent that the "mvn clean" is done! The one failing is a module of this and is residing with a correct relative path to this parent.
>>>
>>> But it is correct that only I have this artifact in my local repository since my colleague are failing to build this due to this problem.
>>>
>>>>
>>>> Try to empty your local repository (~/.m2/repository/xxx/xxx/xxx/ and
>>>> rebuild. I guess without setting the relativePath you will see the same
>>>> error as your colleague.
>>>
>>> The relative path is ".." and should thus be correct. But "cleaning" my ~/.m2/repository/... artifacts is probably a good test to do anyhow.
>>>
>>> Thanks,
>>> Tommy Svensson
>>>
>>>
>>>>
>>>> Hth,
>>>>
>>>> Nick Stolwijk
>>>> On Thu, Nov 28, 2013 at 3:32 PM, Tommy Svensson <to...@natusoft.se> wrote:
>>>>
>>>>> <parent>
>>>>> <groupId>xxx.xxx.xxx</groupId>
>>>>> <artifactId>xxx-shared</artifactId>
>>>>> <version>2.0.26-SNAPSHOT</version>
>>>>> </parent>
>>>>>
>>>>
>>>>
>>>>
>>>> Nick Stolwijk
>>>>
>>>> ~~~ Try to leave this world a little better than you found it and, when
>>>> your turn comes to die, you can die happy in feeling that at any rate you
>>>> have not wasted your time but have done your best ~~~
>>>>
>>>> Lord Baden-Powell
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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: Maven trying to download pom being built and then fails with what seems to be an imaginary error
Posted by Tommy Svensson <to...@natusoft.se>.
Actually, if maven is failing to see the project being built (itself) it would explain both that it tries to download its own pom and that the first module child fails to see the parent.
But what would make it fail to se itself ? It is a valid pom and it is called pom.xml.
Regards,
Tommy Svensson
28 nov 2013 kl. 18:04 skrev Tommy Svensson <to...@natusoft.se>:
> I did remove my local repository files (~/.m2/repository/...) and did an "mvn install" and got this exact problem myself!
>
> I'm however completely failing to understand why. I tried to add "<relativePath>..</relativePath> to the "install" module but that made no difference and since ".." is the one and only relative path to the parent it should make no difference, so I guess that was correct :-). And why does it start with trying to download the pom of the project I'm building. It is available right there in the catalog I'm standing in when running "mvn install". It should be downloading its parent pom, which it does and succeeds with, but it should not be trying to download itself since it is already running itself, and thus already have itself.
>
> Do note that the top parent (the one being successfully downloaded) does not contain any modules! It only provides plugins, properties, etc. It has no knowledge of its children.
>
> Regards,
> Tommy Svensson
>
>
> 28 nov 2013 kl. 17:33 skrev Tommy Svensson <to...@natusoft.se>:
>
>>
>> 28 nov 2013 kl. 15:39 skrev Nick Stolwijk <ni...@gmail.com>:
>>
>>> Probably you have the xxx-shared artifact already in your local repository
>>> from an earlier invocation, so it won't get looked up in Nexus, while your
>>> colleague doesn't.
>>>
>>> I think your parent part of the pom should look something like this:
>>>
>>> <parent>
>>> <groupId>xxx.xxx.xxx</groupId>
>>> <artifactId>xxx-shared</artifactId>
>>> <version>2.0.26-SNAPSHOT</version>
>>> <relativePath>../xxx-shared/pom.xml</relativePath>
>>> </parent>
>>
>> It is *at* this parent that the "mvn clean" is done! The one failing is a module of this and is residing with a correct relative path to this parent.
>>
>> But it is correct that only I have this artifact in my local repository since my colleague are failing to build this due to this problem.
>>
>>>
>>> Try to empty your local repository (~/.m2/repository/xxx/xxx/xxx/ and
>>> rebuild. I guess without setting the relativePath you will see the same
>>> error as your colleague.
>>
>> The relative path is ".." and should thus be correct. But "cleaning" my ~/.m2/repository/... artifacts is probably a good test to do anyhow.
>>
>> Thanks,
>> Tommy Svensson
>>
>>
>>>
>>> Hth,
>>>
>>> Nick Stolwijk
>>> On Thu, Nov 28, 2013 at 3:32 PM, Tommy Svensson <to...@natusoft.se> wrote:
>>>
>>>> <parent>
>>>> <groupId>xxx.xxx.xxx</groupId>
>>>> <artifactId>xxx-shared</artifactId>
>>>> <version>2.0.26-SNAPSHOT</version>
>>>> </parent>
>>>>
>>>
>>>
>>>
>>> Nick Stolwijk
>>>
>>> ~~~ Try to leave this world a little better than you found it and, when
>>> your turn comes to die, you can die happy in feeling that at any rate you
>>> have not wasted your time but have done your best ~~~
>>>
>>> Lord Baden-Powell
>>
>>
>> ---------------------------------------------------------------------
>> 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: Maven trying to download pom being built and then fails with what seems to be an imaginary error
Posted by Tommy Svensson <to...@natusoft.se>.
I did remove my local repository files (~/.m2/repository/...) and did an "mvn install" and got this exact problem myself!
I'm however completely failing to understand why. I tried to add "<relativePath>..</relativePath> to the "install" module but that made no difference and since ".." is the one and only relative path to the parent it should make no difference, so I guess that was correct :-). And why does it start with trying to download the pom of the project I'm building. It is available right there in the catalog I'm standing in when running "mvn install". It should be downloading its parent pom, which it does and succeeds with, but it should not be trying to download itself since it is already running itself, and thus already have itself.
Do note that the top parent (the one being successfully downloaded) does not contain any modules! It only provides plugins, properties, etc. It has no knowledge of its children.
Regards,
Tommy Svensson
28 nov 2013 kl. 17:33 skrev Tommy Svensson <to...@natusoft.se>:
>
> 28 nov 2013 kl. 15:39 skrev Nick Stolwijk <ni...@gmail.com>:
>
>> Probably you have the xxx-shared artifact already in your local repository
>> from an earlier invocation, so it won't get looked up in Nexus, while your
>> colleague doesn't.
>>
>> I think your parent part of the pom should look something like this:
>>
>> <parent>
>> <groupId>xxx.xxx.xxx</groupId>
>> <artifactId>xxx-shared</artifactId>
>> <version>2.0.26-SNAPSHOT</version>
>> <relativePath>../xxx-shared/pom.xml</relativePath>
>> </parent>
>
> It is *at* this parent that the "mvn clean" is done! The one failing is a module of this and is residing with a correct relative path to this parent.
>
> But it is correct that only I have this artifact in my local repository since my colleague are failing to build this due to this problem.
>
>>
>> Try to empty your local repository (~/.m2/repository/xxx/xxx/xxx/ and
>> rebuild. I guess without setting the relativePath you will see the same
>> error as your colleague.
>
> The relative path is ".." and should thus be correct. But "cleaning" my ~/.m2/repository/... artifacts is probably a good test to do anyhow.
>
> Thanks,
> Tommy Svensson
>
>
>>
>> Hth,
>>
>> Nick Stolwijk
>> On Thu, Nov 28, 2013 at 3:32 PM, Tommy Svensson <to...@natusoft.se> wrote:
>>
>>> <parent>
>>> <groupId>xxx.xxx.xxx</groupId>
>>> <artifactId>xxx-shared</artifactId>
>>> <version>2.0.26-SNAPSHOT</version>
>>> </parent>
>>>
>>
>>
>>
>> Nick Stolwijk
>>
>> ~~~ Try to leave this world a little better than you found it and, when
>> your turn comes to die, you can die happy in feeling that at any rate you
>> have not wasted your time but have done your best ~~~
>>
>> Lord Baden-Powell
>
>
> ---------------------------------------------------------------------
> 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: Maven trying to download pom being built and then fails with what seems to be an imaginary error
Posted by Tommy Svensson <to...@natusoft.se>.
28 nov 2013 kl. 15:39 skrev Nick Stolwijk <ni...@gmail.com>:
> Probably you have the xxx-shared artifact already in your local repository
> from an earlier invocation, so it won't get looked up in Nexus, while your
> colleague doesn't.
>
> I think your parent part of the pom should look something like this:
>
> <parent>
> <groupId>xxx.xxx.xxx</groupId>
> <artifactId>xxx-shared</artifactId>
> <version>2.0.26-SNAPSHOT</version>
> <relativePath>../xxx-shared/pom.xml</relativePath>
> </parent>
It is *at* this parent that the "mvn clean" is done! The one failing is a module of this and is residing with a correct relative path to this parent.
But it is correct that only I have this artifact in my local repository since my colleague are failing to build this due to this problem.
>
> Try to empty your local repository (~/.m2/repository/xxx/xxx/xxx/ and
> rebuild. I guess without setting the relativePath you will see the same
> error as your colleague.
The relative path is ".." and should thus be correct. But "cleaning" my ~/.m2/repository/... artifacts is probably a good test to do anyhow.
Thanks,
Tommy Svensson
>
> Hth,
>
> Nick Stolwijk
> On Thu, Nov 28, 2013 at 3:32 PM, Tommy Svensson <to...@natusoft.se> wrote:
>
>> <parent>
>> <groupId>xxx.xxx.xxx</groupId>
>> <artifactId>xxx-shared</artifactId>
>> <version>2.0.26-SNAPSHOT</version>
>> </parent>
>>
>
>
>
> Nick Stolwijk
>
> ~~~ Try to leave this world a little better than you found it and, when
> your turn comes to die, you can die happy in feeling that at any rate you
> have not wasted your time but have done your best ~~~
>
> Lord Baden-Powell
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven trying to download pom being built and then fails with what
seems to be an imaginary error
Posted by Nick Stolwijk <ni...@gmail.com>.
Probably you have the xxx-shared artifact already in your local repository
from an earlier invocation, so it won't get looked up in Nexus, while your
colleague doesn't.
I think your parent part of the pom should look something like this:
<parent>
<groupId>xxx.xxx.xxx</groupId>
<artifactId>xxx-shared</artifactId>
<version>2.0.26-SNAPSHOT</version>
<relativePath>../xxx-shared/pom.xml</relativePath>
</parent>
Try to empty your local repository (~/.m2/repository/xxx/xxx/xxx/ and
rebuild. I guess without setting the relativePath you will see the same
error as your colleague.
Hth,
Nick Stolwijk
On Thu, Nov 28, 2013 at 3:32 PM, Tommy Svensson <to...@natusoft.se> wrote:
> <parent>
> <groupId>xxx.xxx.xxx</groupId>
> <artifactId>xxx-shared</artifactId>
> <version>2.0.26-SNAPSHOT</version>
> </parent>
>
Nick Stolwijk
~~~ Try to leave this world a little better than you found it and, when
your turn comes to die, you can die happy in feeling that at any rate you
have not wasted your time but have done your best ~~~
Lord Baden-Powell
Re: Maven trying to download pom being built and then fails with what seems to be an imaginary error
Posted by Tommy Svensson <to...@natusoft.se>.
28 nov 2013 kl. 16:05 skrev Jörg Schaible <Jo...@scalaris.com>:
> Hi Tommy,
>
> Tommy Svensson wrote:
>
>> My team colleague gets the following error:
>>
>> _____________________________________________________
>> mvn clean or mvn help:effective-pom gives the following error:
>>
>> [INFO] Scanning for projects...
>> Downloading:
>> https://.../nexus/content/groups/public/.../.../.../xxx-shared/2.0.26-SNAPSHOT/maven-metadata.xml
>> Downloading:
>> https://.../nexus/content/groups/public/.../.../.../xxx-shared/2.0.26-SNAPSHOT/xxx-shared-2.0.26-SNAPSHOT.pom
>> [ERROR] The build could not read 1 project -> [Help 1]
>> [ERROR]
>> [ERROR] The project xxx.xxx.xxx:xxx-shared-install:2.0.26-SNAPSHOT
>> [(/home/xxx/repos/xxx/xxx-shared/install/pom.xml) has 1 error ERROR]
>> [Non-resolvable parent POM: Could not find artifact
>> [xxx.xxx.xxx:xxx-shared:pom:2.0.26-SNAPSHOT in nexus
>> [(https://.../nexus/content/groups/public) and 'parent.relativePath
>>
> [<https://.../nexus/content/groups/public%29%20and%20%27parent.relativePath>
>> [' points at wrong local POM @ line 5, column 13 -> [Help 2] ERROR] ERROR]
>> [To see the full stack trace of the errors, re-run Maven with the -e
>> [switch. ERROR] Re-run Maven using the -X switch to enable full debug
>> [logging. ERROR] ERROR] For more information about the errors and possible
>> [solutions, please read the following articles: ERROR] [Help 1]
>> [http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
>> [ERROR] [Help 2]
>>
> [http://cwiki.apache.org/confluence/display/MAVEN/UnresolvableModelException
>> _____________________________________________________
>>
>> The pom it complains about (xxx-shared/install/pom.xml) looks like this:
>> _____________________________________________________
>> <?xml version="1.0" encoding="UTF-8"?>
>> <project xmlns="http://maven.apache.org/POM/4.0.0"
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
>> http://maven.apache.org/xsd/maven-4.0.0.xsd"> <parent>
>> <groupId>xxx.xxx.xxx</groupId>
>> <artifactId>xxx-shared</artifactId>
>> <version>2.0.26-SNAPSHOT</version>
>> </parent>
>> <modelVersion>4.0.0</modelVersion>
>>
>> <artifactId>xxx-shared-install</artifactId>
>> <packaging>pom</packaging>
>>
>> <modules>
>> <module>xxx-base</module>
>> <module>xxx-mb-base</module>
>> <module>xxx-mb-default-config</module>
>> <module>infrastructure</module>
>> </modules>
>>
>> </project>
>> _____________________________________________________
>>
>> There is no <relativePath> in it, nor in any of the other poms in the
>> whole project structure!
>>
>> For me it downloads the first file (maven-metadata.xml) and nothing more,
>> and then cleans OK. I can also do "mvn install" without problem.
>>
>> The
>> _____________________________________________________
>> [ERROR] Non-resolvable parent POM: Could not find artifact
>> [xxx.xxx.xxxi:xxx-shared:pom:2.0.26-SNAPSHOT in nexus
>> [(https://.../nexus/content/groups/public) and 'parent.relativePath
>>
> [<https://.../nexus/content/groups/public%29%20and%20%27parent.relativePath>
>> [' points at wrong local POM @ line 5, column 13 -> [Help 2]
>> _____________________________________________________
>>
>> part seems extremely strange to me.
>
>
> If the <parent/relativePath> element is missing, it's value is by default
> ".." i.e. the parent is searched in your parent directory when you build and
> install the project. If you additionally deploy it, then your project
> artifacts are uploaded to Nexus, but the pom in your parent directory is
> not, i.e. everyone else accessing the project as dependency will fail the
> way you are seeing it.
OK, you might be on to something here!
>
>
>> Also note that the actual project being built/cleaned/etc is
>> xxx-shared:2.0.26-SNAPSHOT!! So maven is actually trying to download the
>> pom being built!! I've personally never ever seen that behavior before in
>> my life and I've used maven quite a lot.
>
>
> Are you sure that the GAV of the POM in the parent folder is still the same
> as the one referenced as parent in your child project?
Well, somewhat sure ...
> If not and it has
> been changed at some stage, then Maven will ignore the pom.xml in the parent
> directory and look in your local repository ... and if it finds there a
> stale one, Maven is satisfied, but your colleague will never have it and his
> build will always fail.
... ok I need to double check this.
>
>
>> Also note that we are building with maven 3.0.x! The biggest difference
>> between me and my colleague is that I'm running on SUSE and she is running
>> on Ubuntu, but that shouldn't make any difference.
>>
>> Any suggestions are appreciated since I'm out of ideas myself.
>
> Hope this gives you some ideas,
> Jörg
>
Thanks
/Tommy
>
> ---------------------------------------------------------------------
> 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: Maven trying to download pom being built and then fails with what seems to be an imaginary error
Posted by Jörg Schaible <Jo...@scalaris.com>.
Hi Tommy,
Tommy Svensson wrote:
> My team colleague gets the following error:
>
> _____________________________________________________
> mvn clean or mvn help:effective-pom gives the following error:
>
> [INFO] Scanning for projects...
> Downloading:
> https://.../nexus/content/groups/public/.../.../.../xxx-shared/2.0.26-SNAPSHOT/maven-metadata.xml
> Downloading:
> https://.../nexus/content/groups/public/.../.../.../xxx-shared/2.0.26-SNAPSHOT/xxx-shared-2.0.26-SNAPSHOT.pom
> [ERROR] The build could not read 1 project -> [Help 1]
> [ERROR]
> [ERROR] The project xxx.xxx.xxx:xxx-shared-install:2.0.26-SNAPSHOT
> [(/home/xxx/repos/xxx/xxx-shared/install/pom.xml) has 1 error ERROR]
> [Non-resolvable parent POM: Could not find artifact
> [xxx.xxx.xxx:xxx-shared:pom:2.0.26-SNAPSHOT in nexus
> [(https://.../nexus/content/groups/public) and 'parent.relativePath
>
[<https://.../nexus/content/groups/public%29%20and%20%27parent.relativePath>
> [' points at wrong local POM @ line 5, column 13 -> [Help 2] ERROR] ERROR]
> [To see the full stack trace of the errors, re-run Maven with the -e
> [switch. ERROR] Re-run Maven using the -X switch to enable full debug
> [logging. ERROR] ERROR] For more information about the errors and possible
> [solutions, please read the following articles: ERROR] [Help 1]
> [http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
> [ERROR] [Help 2]
>
[http://cwiki.apache.org/confluence/display/MAVEN/UnresolvableModelException
> _____________________________________________________
>
> The pom it complains about (xxx-shared/install/pom.xml) looks like this:
> _____________________________________________________
> <?xml version="1.0" encoding="UTF-8"?>
> <project xmlns="http://maven.apache.org/POM/4.0.0"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd"> <parent>
> <groupId>xxx.xxx.xxx</groupId>
> <artifactId>xxx-shared</artifactId>
> <version>2.0.26-SNAPSHOT</version>
> </parent>
> <modelVersion>4.0.0</modelVersion>
>
> <artifactId>xxx-shared-install</artifactId>
> <packaging>pom</packaging>
>
> <modules>
> <module>xxx-base</module>
> <module>xxx-mb-base</module>
> <module>xxx-mb-default-config</module>
> <module>infrastructure</module>
> </modules>
>
> </project>
> _____________________________________________________
>
> There is no <relativePath> in it, nor in any of the other poms in the
> whole project structure!
>
> For me it downloads the first file (maven-metadata.xml) and nothing more,
> and then cleans OK. I can also do "mvn install" without problem.
>
> The
> _____________________________________________________
> [ERROR] Non-resolvable parent POM: Could not find artifact
> [xxx.xxx.xxxi:xxx-shared:pom:2.0.26-SNAPSHOT in nexus
> [(https://.../nexus/content/groups/public) and 'parent.relativePath
>
[<https://.../nexus/content/groups/public%29%20and%20%27parent.relativePath>
> [' points at wrong local POM @ line 5, column 13 -> [Help 2]
> _____________________________________________________
>
> part seems extremely strange to me.
If the <parent/relativePath> element is missing, it's value is by default
".." i.e. the parent is searched in your parent directory when you build and
install the project. If you additionally deploy it, then your project
artifacts are uploaded to Nexus, but the pom in your parent directory is
not, i.e. everyone else accessing the project as dependency will fail the
way you are seeing it.
> Also note that the actual project being built/cleaned/etc is
> xxx-shared:2.0.26-SNAPSHOT!! So maven is actually trying to download the
> pom being built!! I've personally never ever seen that behavior before in
> my life and I've used maven quite a lot.
Are you sure that the GAV of the POM in the parent folder is still the same
as the one referenced as parent in your child project? If not and it has
been changed at some stage, then Maven will ignore the pom.xml in the parent
directory and look in your local repository ... and if it finds there a
stale one, Maven is satisfied, but your colleague will never have it and his
build will always fail.
> Also note that we are building with maven 3.0.x! The biggest difference
> between me and my colleague is that I'm running on SUSE and she is running
> on Ubuntu, but that shouldn't make any difference.
>
> Any suggestions are appreciated since I'm out of ideas myself.
Hope this gives you some ideas,
Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org