How can I get Maven to stop attempting to check for updates for artifacts from a certain group from maven-central-repo?

JavaMaven 2Repository

Java Problem Overview


I'm working on a fairly big Maven project. We have probably around 70 or so individual artifacts, which are roughly split into two libraries of shared code and maybe ten applications which use them. All of these items live in the namespace com.mycompany.*.

Most of the time we're running against snapshot builds. So to do a full build of an application, I might first build the library projects so that they are installed to my local repository (as, say, mycompany-libname-2.4-SNAPSHOT.jar).

The problem is that when I then go build the applications. For some reason, Maven wants to check the main two public repositories (maven-net-repo and java-net-repo) for updates for all of the mycompany-*-SNAPSHOT.jar artifacts. Of course, they aren't found there, and everything eventually resolves back to the versions I just built to my local repository, but I'd like Maven to stop doing this because (a) it makes me feel like a bad net.citizen for constantly checking these repositories for things that will never be there, and (b) it adds some unnecessary and annoying network latency into my build process.

I've taken to running maven in offline mode most of the time to work around this, but that's not ideal since occasionally a dependency on a public library will be updated. So what I'm looking for is a solution which will cause Maven not to check for updates from given repositories for artifacts which meet certain criteria - in this case, I'd be happy if Maven would ignore either SNAPSHOT versions or artifacts which were in the com.mycompany namespace.

Java Solutions


Solution 1 - Java

Also, you can use -o or --offline in the mvn command line which will put maven in "offline mode" so it won't check for updates. You'll get some warning about not being able to get dependencies not already in your local repo, but no big deal.

Solution 2 - Java

Something that is now available in maven as well is

mvn goal --no-snapshot-updates

or in short

mvn goal -nsu

Solution 3 - Java

The updatePolicy tag didn't work for me. However Rich Seller mentioned that snapshots should be disabled anyways so I looked further and noticed that the extra repository that I added to my settings.xml was causing the problem actually. Adding the snapshots section to this repository in my settings.xml did the trick!

<repository>
	<id>jboss</id>
	<name>JBoss Repository</name>
	<url>http://repository.jboss.com/maven2</url>
	<snapshots>
		<enabled>false</enabled>
	</snapshots>
</repository>

Solution 4 - Java

Update: I should have probably started with this as your projects are SNAPSHOTs. It is part of the SNAPSHOT semantics that Maven will check for updates on each build. Being a SNAPSHOT means that it is volatile and subject to change so updates should be checked for. However it's worth pointing out that the Maven super POM configures central to have snapshots disabled, so Maven shouldn't ever check for updates for SNAPSHOTs on central unless you've overridden that in your own pom/settings.


You can configure Maven to use a mirror for the central repository, this will redirect all requests that would normally go to central to your internal repository.

In your settings.xml you would add something like this to set your internal repository as as mirror for central:

<mirrors>
  <mirror>
    <id>ibiblio.org</id>
    <name>ibiblio Mirror of http://repo1.maven.org/maven2/</name>
    <url>http://path/to/my/repository</url>
    <mirrorOf>central</mirrorOf>
  </mirror>
</mirrors>

If you are using a repository manager like Nexus for your internal repository. You can set up a proxy repository for proxy central, so any requests that would normally go to Central are instead sent to your proxy repository (or a repository group containing the proxy), and subsequent requests are cached in the internal repository manager. You can even set the proxy cache timeout to -1, so it will never request for contents from central that are already on the proxy repository.


A more basic solution if you are only working with local repositories is to set the updatePolicy for the central repository to "never", this means Maven will only ever check for artifacts that aren't already in the local repository. This can then be overridden at the command line when needed by using the -U switch to force Maven to check for updates.

You would configure the repository (in your pom or a profile in the settings.xml) as follows:

<repository>
  <id>central</id>
  <url>http://repo1.maven.org/maven2</url>
  <updatePolicy>never</updatePolicy>
</repository>

Solution 5 - Java

Very simple :

In your Super POM parent or setting.xml, use

		<repository>
		<id>central</id>
		<releases>
    		<updatePolicy>never</updatePolicy>
  		</releases>
  		<snapshots>
    		<updatePolicy>never</updatePolicy>
  		</snapshots>
		<url>http://repo1.maven.org/maven2</url>
		<layout>legacy</layout>
	</repository>

It's my tips

Solution 6 - Java

I had some trouble similar to this,

<repository>
	<id>java.net</id>
	<url>https://maven-repository.dev.java.net/nonav/repository</url>
	<layout>legacy</layout>
</repository>
<repository>
	<id>java.net2</id>
	<url>https://maven2-repository.dev.java.net/nonav/repository</url>
</repository>

Setting the updatePolicy to "never" did not work. Removing these repo was the way I solved it. ps: I was following this tutorial about web services (btw, probably the best tutorial for ws for java)

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionTim GilbertView Question on Stackoverflow
Solution 1 - JavaJeff TsayView Answer on Stackoverflow
Solution 2 - JavajoostschoutenView Answer on Stackoverflow
Solution 3 - JavaDennis LassingView Answer on Stackoverflow
Solution 4 - JavaRich SellerView Answer on Stackoverflow
Solution 5 - JavaBruno RégnierView Answer on Stackoverflow
Solution 6 - JavathirdyView Answer on Stackoverflow