Hamcrest class files are included in generated jar


(Ahsan Rabbani) #1

I’ve created a sample project (link below) to demonstrate the issue. If you build this project and look inside the jar you’ll see some extra classes (org.hamcrest package) in there that aren’t actually part of the project. Our old ant script doesn’t do this and that’s the behavior I want. I think it’s because both the junit and mockito dependencies have some of the same classes (org.hamcrest.Matcher for example). What’s the cleanest way to avoid this?

https://docs.google.com/file/d/0B5H_kA6WRTjUazVjZF81T3RodmM/edit?usp=sharing


#2

That’s very strange. It’s actually the java compiler putting the Hamcrest class files into the ‘build/classes’ directory. Gradle is not copying these files or explicitly compiling them. The odd thing is that this happens even if you tell Gradle to use the Ant compile task rather than the new compiler daemon.

My guess is that this is related to the fact that the ‘mockito-all’ jar has the Hamcrest source files bundled, and the ‘junit’ jar file has the Hamcrest class files bundled.

A workaround is to switch to ‘junit-4.11’. That seems to do the trick.


(Ahsan Rabbani) #3

Thanks for the reply. Unfortunately I can’t just upgrade junit across the board like that so I guess I’ll just exclude that package from the jar.


(Peter Niederwieser) #4

What you are seeing is the default javac behavior. That is, the compile class path may contain source files, and referenced source files will be compiled. Question is if it is the right default for Gradle as well. In any case, it should be possible to disable the behavior with:

tasks.withType(JavaCompile) {
    options.compilerArgs = ["-sourcepath", "nonExistingDir"]
}