116
votes

Occasionally maven complains that a particular dependency, which is built and packaged locally, cannot be found in the local repository while building another project that has it as a dependency. We get an error like:

Failed to execute goal on project X: Could not resolve dependencies for project X: Failure to find Y in [archiva repository] was cached in the local repository, resolution will not be reattempted until the update interval of internal has elapsed or updates are forced ->

Where X is the project being built, and Y is the supposedly missing artifact. If you look in the local repository, the artifact is there. This artifact is never installed in our archiva repository, so the problem is purely based in the local repository.

We have tried various profiles in settings.xml, and of course "mvn -U". Neither do any good, nor should they because this artifact never goes any further than the local repository.

The only two things that seem to work are to wait a very long time until maven smartens up, or to completely delete the local repository. Presumably the waiting option is related to the aforementioned update interval.

We have experienced this problem with maven 3.0.2 and 3.0.3. We are using Archiva 1.0.3 (but again this shouldn't be a factor). Any help would be greatly appreciated.

16
Is Maven logging anything while or just before the "waiting?" I.e. is it attempting to connect to an unreachable repository? Also, are the problematic artifacts "-SNAPSHOT"?noahlz
Maven doesn't log anything other than the error I mentioned above. And yes this is a snapshot dependency.user1686620
Have you installed the build package before you try to build the second project?khmarbaise
I like how the error message is a run-on, not a grammatically correct sentence. This way, we don't know for sure if it cannot find Y or if Y was cached locally, or both. Anyway, I have a similar problem. I was able to resolve it with the -U option because my dependencies are in my company's internal repo. Why aren't the artifacts you need deployed to your company's internal repository?jyoungdev

16 Answers

91
votes

The local Maven repo tracks where artifacts originally came from using a file named "_maven.repositories" in the artifact directory. After removing it, the build worked. This answer fixed the problem for me.

44
votes

As the options here didn't work for me, I'm sharing how I solved it:

My project has a parent project (with its own pom.xml) that has many children modules, one of which (A) has a dependency to another child (B). When I tried mvn package in A, it didn't work because B could not be resolved.

Executing mvn install in the parent directory did the job. After that, I could do mvn package inside of A and only then it could find B.

20
votes

Even in offline mode, maven will check remote repositories if there is a _remote.repositories marker for the dependency. If you need to operate in offline mode, you may need to delete these files.

The simple shell command below deletes these marker files. This is safe to do if you only use offline mode for the machine. I would NOT do this on a machine that needs to pull files down from the web.

I have used this strategy on a build server that is disconnected from the web. We have to transfer the repository to it, delete the marker files and then run in offline mode.

On Linux / Unix you can delete the remote repository marker files this way:

cd ~/.m2
find . -name "_remote.repositories" -type f -delete
10
votes

When this happened to me, it was because I'd blindly copied my settings.xml from a template and it still had the blank <localRepository/> element. This means that there's no local repository used when resolving dependencies (though your installed artifacts do still get put in the default location). When I'd replaced that with <localRepository>${user.home}\.m2\repository</localRepository> it started working.

For *nix, that would be <localRepository>${user.home}/.m2/repository</localRepository>, I suppose.

10
votes

Maven remembers when it didn't find something. The key is "resolution will not be reattempted until the update interval of internal has elapsed or updates are forced ->"

The quick solution is to delete your local "repository" subdirectory for the problem artifact - assuming you have fixed the problem with it. :)

mvn -U will force update from remote repository - again, assuming you have now populated remote with said artifact.

4
votes

If you have <repositories/> defined in your pom.xml apparently your local repository is ignored.

3
votes

Catch all. When solutions mentioned here don't work(happend in my case), simply delete all contents from '.m2' folder/directory, and do mvn clean install.

2
votes

Even I faced this issue and solved it with 2 ways:

1) In your IDE select project and clean all projects then install all the maven dependencies by right clicking on project -> go to maven and Update project dependencies select all projects at once to install the same. Once this is done run the particular project

2) Else What you can do is check in the pom.xml for the dependencies for which you are getting error and "mvn clean install" those dependent project first and the install maven dependencies of the current project in which you facing issue. By this the dependencies of the local project will be build and jars will be created.

0
votes

I run to the similar problem when my new project depend on oracle jdbc jar(which I have installed in my local repository and work well for other projects). I tried -U option ,deleting .lastupdate file or the whole directory and downlaod again,but it did not work. finally,I deleted the directory and installed it locally again,it works.

0
votes

One of the errors I found around Maven is when I put my settings.xml file in the wrong directory. It has to be in .m2 folder under your user home dir. Check to make sure that is in the right place (along with settings-security.xml if you are using that).

0
votes

I had DependencyResolutionException in Ubuntu Linux when I've installed local artifacts via a shell script. The solution was to delete the local artifacts and install them again "manually" - calling mvn install:install-file via terminal.

0
votes

This happened because I had http instead of https in this:

<repository>
    <id>jcenter</id>
    <name>jcenter-bintray</name>
    <url>https://jcenter.bintray.com</url>
</repository>
0
votes

check if if your artifact Y have packaging set to "jar". If you have defined it as "war" by error or copy paste, it will show this strange "was cached in the local repository, resolution will not be reattempted until the update interval of internal has elapsed or updates are forced". I would expect something like "artifact Y is war, jar type expected".

0
votes

In my case I needed project Y to be a WAR to be deployed through Tomcat, as well as it needed to be a JAR to be able to add it as a dependency in project X.

So in project Y's pom.xml, I added this plugin to create a JAR along with the WAR:

            <plugin>
                <artifactId>maven-war-plugin</artifactId>
                <version>3.2.2</version>
                <configuration>
                    <attachClasses>true</attachClasses>
                    <classesClassifier>classes</classesClassifier>
                </configuration>
            </plugin>

And while adding the dependency of project Y in project X's pom.xml, I had to add a classifier:

        <dependency>
            <groupId>groupId.of.project.Y</groupId>
            <artifactId>project.Y</artifactId>
            <version>1.0-SNAPSHOT</version>
            <classifier>classes</classifier>
        </dependency>

Note: when you build project Y, you will see 2 packagings in the target folder: project-Y.war and project-Y-classes.jar, so that's why while importing you are specifying the classes classifier to import the JAR and not the WAR.

0
votes

In my case I had to add mavenLocal() in root level gradle dependency

mavenCentral()
mavenLocal()
-1
votes

I had the same error from a different cause: I'd created a starter POM containing our "good practice" dependencies, and built & installed it locally to test it. I could "see" it in the repo, but a project that used it got the above error. What I'd done was set the starter POM to pom, so there was no JAR. Maven was quite correct that it wasn't in Nexus -- but I wasn't expecting it to be, so the error was, ummm, unhelpful. Changing the starter POM to normal packaging & reinstalling fixed the issue.