espresso's dependencies pull hamcrest libs separately

[GoogleCodeExporter]

What steps will reproduce the problem?
1. clone the git repo
2. change to the project directory and hit mvn install
3. configure a test project with

<dependency>
    <groupId>com.google.android.apps.common.testing</groupId>
    <artifactId>espresso</artifactId>
    <version>${testkit.version}</version>
</dependency>
<dependency>
    <groupId>com.google.android.apps.common.testing</groupId>
    <artifactId>testrunner</artifactId>
    <version>${testkit.version}</version>
</dependency>
<dependency>
    <groupId>com.google.android.apps.common.testing</groupId>
    <artifactId>testrunner-runtime</artifactId>
    <version>${testkit.version}</version>
</dependency>

where ${testkit.version} expands to the current 1.0-SNAPSHOT.

Expected:
No build errors

Got:
Error generating final archive: Found duplicate file for APK: LICENSE.txt
Origin 1: 
path\to\.m2\repository\org\hamcrest\hamcrest-core\1.1\hamcrest-core-1.1.jar
Origin 2: 
path\to\.m2\repository\org\hamcrest\hamcrest-integration\1.1\hamcrest-integratio
n-1.1.jar

Workaround:

To get it using the -all library, I temporarily added some exclusions like this:

<dependency>
    <groupId>org.hamcrest</groupId>
    <artifactId>hamcrest-all</artifactId>
    <version>${hamcrest.version}</version>
</dependency>
<dependency>
    <groupId>com.google.android.apps.common.testing</groupId>
    <artifactId>espresso</artifactId>
    <version>${testkit.version}</version>
    <exclusions>
        <exclusion>
        <groupId>org.hamcrest</groupId>
        <artifactId>hamcrest-core</artifactId>
    </exclusion>
        <exclusion>
        <groupId>org.hamcrest</groupId>
        <artifactId>hamcrest-library</artifactId>
    </exclusion>
        <exclusion>
        <groupId>org.hamcrest</groupId>
        <artifactId>hamcrest-integration</artifactId>
    </exclusion>
   </exclusions> 
</dependency>
...

I guess this is actually a bug with hamcrest, but given the fact that it can be 
circumvented by just depending on -all it might be fixable here.

Original issue reported on code.google.com by m...@thomaskeller.biz on 13 Nov 2013 at 12:41

[GoogleCodeExporter]

I'm having the same problem. It was only occuring when using Junit 3.

Original comment by zboa...@gmail.com on 2 Dec 2013 at 11:20

[GoogleCodeExporter]

As outlined on the wiki, you can also use the separate dependencies to avoid 
this issue. Given that there are workarounds, resolving this bug.

Original comment by vale...@google.com on 9 Jan 2014 at 7:23

• Changed state: WontFix

[GoogleCodeExporter]

Erm, simply 'WontFix'ing this bug is not sufficient IMHO.

Yes, the wiki describes an alternative path to specifiy dependencies one by one 
by manually copying the libraries into the project, the point of this bug 
however is that the default approach, depending on   the mavencentral 
deployment is problematic, and most people will actually go down that route.

So what could you do about that? Well, either depend in your pom on 
hamcrest-all, like outlined in the bug's description, or _at least_ print a big 
fat warning in your deployment instructions that note that remote dependency 
deployment is otherwise broken.

Thank you!

Original comment by m...@thomaskeller.biz on 9 Jan 2014 at 10:20