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

carlspring
  • 31,231
  • 29
  • 115
  • 197
Dave
  • 15,639
  • 133
  • 442
  • 830
  • Have you read [Introduction to the Dependency Mechanism](https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html)? Maybe _Transitive Dependencies_ applies here. – Gerold Broser Oct 24 '14 at 21:28
  • 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. ;-) – Gerold Broser Oct 24 '14 at 21:36
  • Check your configuration for your repositories and see if there is a updatePolicy set in any way. – khmarbaise Oct 24 '14 at 23:42
  • 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. – Dave Oct 27 '14 at 13:46
  • adding repositories configuration (probably from `settings.xml`) will sure help to troubleshoot the problem. – JBaruch Oct 30 '14 at 17:14

2 Answers2

9

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>

Community
  • 1
  • 1
janDro
  • 1,426
  • 2
  • 11
  • 24
  • What happens if you build two or more snapshots the same day? – рüффп Oct 09 '20 at 13:08
  • 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. – kriegaex May 08 '21 at 05:40
  • 3
    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. – kriegaex May 08 '21 at 09:31
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?

Robert Scholte
  • 11,889
  • 2
  • 35
  • 44
  • 1
    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. – lucasweb Jul 27 '15 at 21:27
  • 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. – kriegaex May 08 '21 at 09:32
  • 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! – Gunnar May 30 '22 at 18:45