I have a Maven project that so far used to compile without problems. Today, when I run mvn clean package -U, I get:
[ERROR] Failed to execute goal on project myproj: Could not resolve dependencies for project org.myorg.myproj:myproj:jar:1.0-SNAPSHOT: The following artifacts could not be resolved: javax.servlet:javax.servlet-api:src:sources:3.0.1, org.eclipse.jetty:jetty-servlet:src:sources:8.1.2.v20120308, org.eclipse.jetty:jetty-server:src:sources:8.1.2.v20120308, org.eclipse.jetty:jetty-webapp:src:sources:8.1.2.v20120308, commons-io:commons-io:src:sources:2.4: Could not find artifact javax.servlet:javax.servlet-api:src:sources:3.0.1 in MyRepo (http://maven.myorg.org:9001/nexus/content/repositories/myrepo/) -> [Help 1]
I tried to with a fresh local Maven repository (rm -fr ~/.m2/repository) but that did not make any difference.
Why does Maven try to find source/src artefacts? Any ideas where the problem might lie?
Edit: My dependencies (as seen using mvn help:effective-pom) do not have any source classifiers. For example, the dependency on the jetty-server mentioned in the error message reads as follows:
<dependency>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-server</artifactId>
<version>8.1.2.v20120308</version>
<scope>compile</scope>
</dependency>
Solution: With the help of @AlessandroSantini and @brian-topping, I finally identified the problem. One of my indirect dependencies had a <classifier>sources</classifier> and <type>src</type>. (mvn help:effective-pom did not show these indirect dependencies, and mvn dependency:tree failed with the above error message, too; eventually, a grep -r 'jetty-server' ~/.m2/repository/ -C 3 identified the artifact with the messed up dependency.)
It turned out that one of my own SBT projects required the (non-existing) source artifacts for one of its dependencies: I used SBT’s withSources() where I should have used sbteclipe’s EclipseKeys.withSource := true to get the sources in Eclipse.
Do you have any dependencies on public snapshots? I’d take a look at the output of
mvn dependency:treeand see if you can find a transitive dependency that is including the sources somehow. Maybe one of the transitives have changed since your last build and they messed something up.