views:

2793

answers:

1

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.

+4  A: 

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/&lt;/name&gt;
    <url>http://path/to/my/repository&lt;/url&gt;
    <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&lt;/url&gt;
  <updatePolicy>never</updatePolicy>
</repository>
Rich Seller
We actually do have a central repository already, but of course we don't publish snapshot builds to it, so presumably I'd still get failed update checks with the proxy/mirror in place - I'm looking for a way to get Maven to not check for updates at all for these artifacts.
Tim Gilbert
It's worth also setting up a logical repository on your central repository for your SNAPSHOTs. This means they can be shared between your developers and you don't all have to build them all locally. You'll then be getting the full benefit of SNAPSHOTs by picking up changes to any SNAPSHOT dependencies as soon as they're pushed to the remote repository.
Rich Seller
Thanks - the updatePolicy flag looks like exactly what I was looking for.
Tim Gilbert
Nexus also allows you to configure rules to prevent any requests for company artifacts to go external.
Brian Fox