Maven dependency resolution problems caused by child module having a different parent version from top level parent pom.xml

The moral of the story is: When working on a multi-module project,
remember to update ALL pom.xml files, not just one version. Update
from the top-level often.

I'm working on a multi-module Maven project, and Bamboo (our
continuous integration server) is set up so that whenever a release is
done, the version number is incremented.

Now we have most of our dependencies set up in the parent-level
pom.xml. One of them is a client jar to our web services backend. Call
it services-client.jar

I've just spent an afternoon trying to sort out this very confusing
situation where I'd already updated the dependency in our pom.xml to
services-client-19.jar, but whenever I did a build, I would also get
services-client-17.jar.

I thought at first that it was an IDE problem, IntelliJ getting
confused with its caches, so I tried all sorts of fixes at that level
- cleared cache, recreated project file, reimport all Maven projects,
manually delete jars in settings - nothing worked.

I then went to command-line, removed all versions of
services-client*.jar from local repo, then did a build. I grep'd
through all my pom.xml files, and I saw that I only had one reference
to services-client, it was in top-level pom.xml and and it was version
19.


$ find . -name "pom.*" -exec grep -i "0.1203." {} /dev/null \;
./domain/pom.xml: <version>0.1203.0.134-SNAPSHOT</version>
./extension/pom.xml: <version>0.1203.0.134-SNAPSHOT</version>
./front-end/pom.xml: <version>0.1203.0.134-SNAPSHOT</version>
./pom.xml: <version>0.1203.0.138-SNAPSHOT</version>

While this was using services-client-19.jar:

./pom.xml: <version>0.1203.0.138-SNAPSHOT</version>

The child-level modules were pointing to an older parent pom file, one
that Bamboo already installed to our company repository.

The parent version used in the child modules:

./domain/pom.xml: <version>0.1203.0.134-SNAPSHOT</version>

Was using services-client-17.jar

So whenever did "mvn clean install" the project from the
parent-level, Maven was following this sequence when resolving the
dependencies:

1) Maven goes to child modules and builds

2) In /domain/pom.xml - it sees the reference to older parent pom,
fetches from repository, starts to resolve dependencies, fetches older
services client - services-client-17.jar.

3) services-client-17.jar gets installed in local repo

4) During build, code that uses services-client-19.jar code fails
compilation because that jar never actually gets installed until Maven
gets to the top most pom.xml

I haven't verified this with the Maven mailing list yet, this is just
my interpretation of what the problems have been.


The moral of the story is: When working on a multi-module project,
remember to update ALL pom.xml files, not just one version. Update
from the top-level often.


I have updated at the top level and the parent versions are now
consistent - 0.1203.0.140 all the way.

$ find . -name "pom.*" -exec grep -i "0.1203." {} /dev/null \;
./domain/pom.xml: <version>0.1203.0.140-SNAPSHOT</version>
./extension/pom.xml: <version>0.1203.0.140-SNAPSHOT</version>
./front-end/pom.xml: <version>0.1203.0.140-SNAPSHOT</version>
./pom.xml: <version>0.1203.0.140-SNAPSHOT</version>

Dear Ticketmaster Australia: if a gig is sold out, just fucking tell me. I can handle it.

What I can't handle is being treated like an idiot and having my time wasted.

The fact that searching is allowed would naturally lead any user to
think that there is something to be found. But in this case, widening
my search to "Best Available" and "Any Price" still returns nothing!
If that's the case, why allow searches at all?

Instead of wasting everyone's time letting them search for tickets
that do not exist, just mention it upfront on the site if tickets have
sold out already. Don't waste my goddamn time!

What were your marketing fuckwits thinking? "Oh, maybe they'll stay
around longer on the site and buy tickets to something else!"

That's not how it works, assholes.

We just get pissed off and tell everyone your website is a piece of shit.

Unfortunately, consumers don't have any options as you and Ticketek
have the big events pretty much between yourselves.

Fuck. This.