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 <[email protected]>: > 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 <[email protected]>: > >> 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 <[email protected]>: >> >>> 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 <[email protected]>: >>> >>>> >>>> 28 nov 2013 kl. 15:39 skrev Nick Stolwijk <[email protected]>: >>>> >>>>> 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 <[email protected]> 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: [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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
