Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

maven can't find my local artifacts

Tags:

maven

I can't seem to run mvn -o package because it complains with

The repository system is off line but the artifact com.liferay.portal:util-bridges:jar:6.1.20 is not available in the local repository.

But I checked my local repository and that artifact does exist there. I also tried the solution of setting updatePolicy to never in the settings.xml file but that failed to work.

like image 928
George Lee Avatar asked May 31 '13 22:05

George Lee


People also ask

Where is my local Maven repository?

The Maven local repository is located in the /home/. m2 directory, the folder is probably hidden.

Where are artifacts stored in Maven?

The first place that Maven looks for artifacts is in the local repository, which is the local cache where Maven stores all of the artifacts it has downloaded or found elsewhere. The default location of the local repository is the . m2/repository/ directory under the user's home directory.

What is m2 folder in Maven?

m2 folder is the default folder used by maven to store its: settings. xml file which specifies properties, like the central repository to download your dependencies, the location of the so-called localRepository. by default, the localRepository in which maven stores all the dependencies your project might need to run.


1 Answers

Prior to Maven 3.0.x, Maven did not track the origin of files in the local repository.

This could result in build issues, especially if you were building something that listed the (now dead) very borked java.net2 repository... Not only did that repository change released artifacts (extremely bad and evil practice) but it also published artifacts at the same coordinates as artifacts on central but with different content (unbelievably evil)

So you could have the build work (because you had commons-io:commons-io:2.0 from central) wipe your local repo and the build fails (because you now get commons-io:commons-io:2.0 from java.net2 which was a completely different artifact with different dependencies in the pom) or vice versa.

The above situation is one of the drivers for using a maven repository manager, because that allows you to control the subset of a repository that you expose downstream and the order in which artifacts are resolved from multiple repositories (usually referred to as routing rules)

In any case, when maven switched to Aether as the repository access layer, the decision was made to start tracking where artifacts come from.

So with Maven 3.0.x, when an artifact is downloaded from a repository, maven leaves a _maven.repositories file to record where the file was resolved from. If you are building a project and the effective list of repositories does not include the location that the artifact was resolved from, then Maven decides that it is as if the artifact was not in the cache, and will seek to re-resolve the artifact...

There are a number of bugs in 3.0.x though... The most critical being how offline is handled... Namely: when offline, maven 3.0.x thinks there are no repositories, so will always find a mismatch against the _maven.repositories file!!!

The workaround for Maven 3.0.x is to delete these files from your local cache, eg

$ find ~/.m2/repository -name _maven.repositories -exec rm -v {} \; 

The side effect is that you loose the protections that Maven 3.0.x is trying to provide.

The good news is that Maven 3.1 will have the required fix (if we can ever get our act together and get a release out the door)

With Maven 3.1 when in offline mode the _maven.repositories file is (semi-)ignored, and there is also an option to ignore that file for online builds (referred to as legacy mode)

At this point in time (June 1st 2013) the 4th attempt to cut a release that meets the legal and testing requirements is in progress... So, assuming that the 4th time is lucky, I would hope to see 3.1.0-alpha-1 released in 3-4 days time... But it could be longer given that we want to give the changes in 3.1 enough time to soak to ensure uses builds don't break (there was a change in an API exposed (by accident-ish - the API is needed by the site and dependency plugin) that plugin authors have depended on (even though they shouldn't have) so there is potential, though we think we have all the bases covered)

Hope that answers your question (and maybe a few more you didn't know you had ;-) )

like image 200
Stephen Connolly Avatar answered Oct 18 '22 14:10

Stephen Connolly