So we recently implemented a Nexus server for our maven repository manager. We proxy about 30 outside repositories and funnel them all into a single group, which we point to in the settings.xml in mirrors with a *.
Before that, we didn't have this problem... and now we do. It frustrates me that there is little information on this dummy jar, where it comes from, or where I can get it to stop these failures. I have been researching for a few days and come up short with nothing. I am hoping the community might be able to help.
18-Oct-2012 22:50:31 [ERROR] BUILD ERROR
18-Oct-2012 22:50:31 [INFO] ------------------------------------------------------------------------
18-Oct-2012 22:50:31 [INFO] Unable to generate classpath: org.apache.maven.artifact.resolver.ArtifactResolutionException: Unable to get dependency information: Unable to read the metadata file for artifact 'org.apache.maven.surefire:surefire-junit4:jar': Cannot find parent: org.apache.maven.surefire:surefire-providers for project: null:surefire-junit4:jar:null for project null:surefire-junit4:jar:null
18-Oct-2012 22:50:31 org.apache.maven.surefire:surefire-junit4:jar:2.12
18-Oct-2012 22:50:31
18-Oct-2012 22:50:31 from the specified remote repositories:
18-Oct-2012 22:50:31 central (http://repo1.maven.org/maven2),
18-Oct-2012 22:50:31 JavaNet-mirror (http://maven:8081/nexus/content/repositories/Java.net/),
18-Oct-2012 22:50:31 Releases (https://nexus:8443/nexus/content/repositories/releases/)
18-Oct-2012 22:50:31
18-Oct-2012 22:50:31 Path to dependency:
18-Oct-2012 22:50:31 1) dummy:dummy:jar:1.0
We had a similar problem where a developer had put a class with the name of "TestUtil" in the test hierarchy, when the class wasn't actually related to unit testing at all. Renaming the class into something that didn't contain Test prefix fixed the issue for us. Don't know what it is about though.
AFAIK dummy.jar is something used internally by surefire plugin but is normally never exposed to end user. "dummy.jar" can be seen in surefire plugin source code (example1 and example2)
So in our case the class "TestUtil" caused the problem to appear, leading to similar situation, but to verify it's not something more logical always do a run of maven with -X
debug log flag set.
It sounds like a network problem.
Either something is blocking the internet access (a firewall or antivirus, just disable that temporarily to download the dependencies).
Or the jar is to big to be downloaded, from http://maven.apache.org/wagon/wagon-providers/wagon-http-lightweight/
Known Limitation:
The main limitation is that you can't download data that doesn't fit entirely into memory.
A fix for this is to increase the memory for Maven:
export MAVEN_OPTS="-Xmx1024m"
See: Maven failing to download jar dependencies
In my case I wasn't specifying the version of the surefire plugin. e.g.:
<build>
<plugins>
<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<includes>
<include>**/*_UT.java</include>
<include>**/*_FT.java</include>
</includes>
</configuration>
</plugin>
</plugins>
</build>
... which works great. But then I upgraded my Maven command-line client and got this. The solution varies depending on what you want to do (add missing artifact to your corporate repo, hard-code the surefire version, downgrade Maven), but understanding the why was the important part for me.
Hope this helps someone out there.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With