Motto:
Caches are bugs waiting to happen. Rob Pike
The last two days I was hunting an issue in the Maven/Tycho based build of VIATRA: some artifacts from Maven Central were not found anymore, seemingly without any related change. A more detailed analysis has shown that the issue is specific to the build server at the Eclipse Foundation: in all other cases the builds run successfully.
When looking at the debug output of the build (the -X switch for mvn is truly a killer feature…) it was interesting that the build did not try to download the dependency from Maven Central nor from the mirror set up for builds at the Hudson instance at eclipse. Given that the first twenty-two modules compiled (with dependencies to Maven Central) this made no sense.
After managing the sanity loss and calling for help (thanks Ábel and Balázs) we have managed to identify that the settings.xml used on Hudson caused the problem. After calling for more help (thanks for the quick help from webmaster) I have finally managed to find out the root cause of the issue: repository identifier clash caused by the maven central mirror and a dependency issue.
For performance and network utilization reasons a mirror for maven central was set up about a month ago using the following fragment:
<mirrors> <mirror> <id>repo.eclipse.org</id> <name>Eclipse Central Proxy</name> <url>https://repo.eclipse.org/content/repositories/maven_central/</url> <mirrorOf>central</mirrorOf> </mirror> </mirrors>
Our problematic bundle had a repository declaration as follows:
<repositories> <repository> <id>repo.eclipse.org</id> <url>https://repo.eclipse.org/content/groups/releases/</url> </repository> </repositories>
What happened here is that we declared some repositories with the same identifier as the proxy repository declared by webmaster, and Maven got confused, and thought that everything from Central is reachable from our declared dependency repository. Changing the identifier to avoid the name clash solved this issue nicely.
Now only one question remains: why was this issue not found earlier. The answer is trivial: the plugins were available in the local repository, effectively hiding the unresolvable dependencies. A completely unrelated cleanup of the local repository however has brought forth this issue, causing much headache to find.
The main lesson we learned here: DO NOT reuse the same repository identifier for multiple repositories. It can cause very subtle, hard to debug issues in the long run. However, there are a few other aspects you have to keep in mind:
- All repositories and plugin repositories defined in your parent project are also inherited, so their name should also be unique.
- Identifier clash might not be a problem in case of deployment repositories, but have not tested this aspect yet.
- A more specific lesson for Eclipse projects building on Foundation Servers:
DO NOT use the identifier “repo.eclipse.org” for your repositories. Maybe it is worth checking whether the identifier is used (e.g. use following the github search link to check projects developed or mirrored to the Eclipse Github organization), and update accordingly.Update: the mirror repository id was updated to “eclipse.maven.central.mirror” that should not clash with manual repository names.
