How do I prevent Maven from downloading maven-metadata.xml for an artifact that I already have in my repo?
Asked Answered
D

2

6

I’m using Maven 3.2. I have this dependency in my pom.xml file (a WAR project)

            <dependency>
                    <groupId>joda-time</groupId>
                    <artifactId>joda-time</artifactId>
                    <version>1.6.2</version>
                    <scope>provided</scope>
            </dependency>

Whenever I run any phase for my pom (e.g. “mvn install”), the app always attempts to download some metadata about the dependency …

Downloading: http://repo.spring.io/milestone/joda-time/joda-time/maven-metadata.xml

How do I tell Maven to stop doing that? I already have the artifact cached in my local Maven repo.

Thanks, - Dave

Dorran answered 24/10, 2014 at 20:35 Comment(5)
Have you read Introduction to the Dependency Mechanism? Maybe Transitive Dependencies applies here.Silvers
Or maybe it's to remind you to look into the .xml to realize that joda-time 1.6.2 is four years old and the latest version is 2.5. ;-)Silvers
Check your configuration for your repositories and see if there is a updatePolicy set in any way.L
I have no "updatePolicy" settings in any of my repositories. Also, I had to use an older time of joda-time because that is the version JBoss 7.1.3.Final is using.Dorran
adding repositories configuration (probably from settings.xml) will sure help to troubleshoot the problem.Chausses
T
10

Maybe the update policies need to be specified explicitly. See this answer: Why is Maven downloading the maven-metadata.xml every time?

<pluginRepositories>
<pluginRepository>
    <id>central</id>
    <url>http://gotoNexus</url>
    <snapshots>
        <enabled>true</enabled>
        <updatePolicy>daily</updatePolicy>
    </snapshots>
    <releases>
        <enabled>true</enabled>
        <updatePolicy>never</updatePolicy>
    </releases>
</pluginRepository>

Tweet answered 30/10, 2014 at 16:57 Comment(3)
What happens if you build two or more snapshots the same day?Gablet
This does not work in my case. I have two repositories in my POM, the first one repeating the Maven Central definition from the super POM in order to make it to be found first (because repositories defined in the project POM are queried before ones from the super POM). Still, even though Central contains my artifacts, they are cached locally already, I configured update policy to never and even replaced my version ranges by specific versions, the metadata from the custom repository is always downloaded. I have no repositories in my settingx.xml.Sadye
OK, it did work. What I did not realise at first, was the fact that not my own POM had version ranges, but some transitive ones did. I had to fix their versions in my POM's dependencyManagement section, then finally Maven stopped trying to download the meta data files. I am writing this for the benefit of enyone getting into the same situation, instead of just deleting my previous comment.Sadye
I
7

This means that somewhere in your dependency tree either a SNAPSHOT or a version-range is used (direct or as transitive dependency). For both cases the solution is the same: lock the version to a specific release. Did you lock it as direct dependency or within dependencyManagement?

Inclusive answered 1/11, 2014 at 12:20 Comment(3)
In my case aws-java-sdk-core had a dependency on joda-time that used a version range. Excluding the dependency from aws-java-sdk-core and including joda-time directly in my POM with a locked version resolved this issue.Crossfertilize
Transitive dependencies with version ranges was the problem in my case, see my comments under the accepted answer. Thanks for your answer, it was instrumental in me figuring out what was going on.Sadye
Although not in the specific scenario this answer provided some very good hints for mine! It was indeed a transitive with a version range and I was using the resolver programatically. Thanks!Opalopalesce

© 2022 - 2024 — McMap. All rights reserved.