Do not bundle README.txt in class jars

[bubenheimer]

Both hamcrest-core-2.1.jar and hamcrest-library-2.1.jar contain README.txt, which prevents me from running Android tests due to a name clash.

[lbenedetto]

I am having the same issue. Temporary workaround is to downgrade hamcrest back to 1.3

org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':app:transformResourcesWithMergeJavaResForDebugAndroidTest'.
	at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:110)
	at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:77)
	at org.gradle.api.internal.tasks.execution.OutputDirectoryCreatingTaskExecuter.execute(OutputDirectoryCreatingTaskExecuter.java:51)
	at org.gradle.api.internal.tasks.execution.SkipUpToDateTaskExecuter.execute(SkipUpToDateTaskExecuter.java:59)
	at org.gradle.api.internal.tasks.execution.ResolveTaskOutputCachingStateExecuter.execute(ResolveTaskOutputCachingStateExecuter.java:54)
	at org.gradle.api.internal.tasks.execution.ValidatingTaskExecuter.execute(ValidatingTaskExecuter.java:59)
	at org.gradle.api.internal.tasks.execution.SkipEmptySourceFilesTaskExecuter.execute(SkipEmptySourceFilesTaskExecuter.java:101)
	at org.gradle.api.internal.tasks.execution.FinalizeInputFilePropertiesTaskExecuter.execute(FinalizeInputFilePropertiesTaskExecuter.java:44)
	at org.gradle.api.internal.tasks.execution.CleanupStaleOutputsExecuter.execute(CleanupStaleOutputsExecuter.java:91)
	at org.gradle.api.internal.tasks.execution.ResolveTaskArtifactStateTaskExecuter.execute(ResolveTaskArtifactStateTaskExecuter.java:62)
	at org.gradle.api.internal.tasks.execution.SkipTaskWithNoActionsExecuter.execute(SkipTaskWithNoActionsExecuter.java:59)
	at org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecuter.execute(SkipOnlyIfTaskExecuter.java:54)
	at org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter.execute(ExecuteAtMostOnceTaskExecuter.java:43)
	at org.gradle.api.internal.tasks.execution.CatchExceptionTaskExecuter.execute(CatchExceptionTaskExecuter.java:34)
	at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.run(EventFiringTaskExecuter.java:51)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:300)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:292)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:174)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:90)
	at org.gradle.internal.operations.DelegatingBuildOperationExecutor.run(DelegatingBuildOperationExecutor.java:31)
	at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter.execute(EventFiringTaskExecuter.java:46)
	at org.gradle.execution.taskgraph.LocalTaskInfoExecutor.execute(LocalTaskInfoExecutor.java:42)
	at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$BuildOperationAwareWorkItemExecutor.execute(DefaultTaskExecutionGraph.java:277)
	at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$BuildOperationAwareWorkItemExecutor.execute(DefaultTaskExecutionGraph.java:262)
	at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$ExecutorWorker$1.execute(DefaultTaskPlanExecutor.java:135)
	at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$ExecutorWorker$1.execute(DefaultTaskPlanExecutor.java:130)
	at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$ExecutorWorker.execute(DefaultTaskPlanExecutor.java:200)
	at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$ExecutorWorker.executeWithWork(DefaultTaskPlanExecutor.java:191)
	at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$ExecutorWorker.run(DefaultTaskPlanExecutor.java:130)
	at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:63)
	at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:46)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:55)
	at java.lang.Thread.run(Thread.java:745)
Caused by: com.android.builder.merge.DuplicateRelativeFileException: More than one file was found with OS independent path 'README.txt'
	at com.android.builder.merge.StreamMergeAlgorithms.lambda$acceptOnlyOne$2(StreamMergeAlgorithms.java:75)
	at com.android.builder.merge.StreamMergeAlgorithms.lambda$select$3(StreamMergeAlgorithms.java:100)
	at com.android.builder.merge.IncrementalFileMergerOutputs$1.create(IncrementalFileMergerOutputs.java:86)
	at com.android.builder.merge.DelegateIncrementalFileMergerOutput.create(DelegateIncrementalFileMergerOutput.java:61)
	at com.android.build.gradle.internal.transforms.MergeJavaResourcesTransform$1.create(MergeJavaResourcesTransform.java:386)
	at com.android.builder.merge.IncrementalFileMerger.updateChangedFile(IncrementalFileMerger.java:221)
	at com.android.builder.merge.IncrementalFileMerger.mergeChangedInputs(IncrementalFileMerger.java:190)
	at com.android.builder.merge.IncrementalFileMerger.merge(IncrementalFileMerger.java:77)
	at com.android.build.gradle.internal.transforms.MergeJavaResourcesTransform.transform(MergeJavaResourcesTransform.java:419)
	at com.android.build.gradle.internal.pipeline.TransformTask$2.call(TransformTask.java:239)
	at com.android.build.gradle.internal.pipeline.TransformTask$2.call(TransformTask.java:235)
	at com.android.builder.profile.ThreadRecorder.record(ThreadRecorder.java:102)
	at com.android.build.gradle.internal.pipeline.TransformTask.transform(TransformTask.java:230)
	at sun.reflect.GeneratedMethodAccessor663.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:73)
	at org.gradle.api.internal.project.taskfactory.IncrementalTaskAction.doExecute(IncrementalTaskAction.java:50)
	at org.gradle.api.internal.project.taskfactory.StandardTaskAction.execute(StandardTaskAction.java:39)
	at org.gradle.api.internal.project.taskfactory.StandardTaskAction.execute(StandardTaskAction.java:26)
	at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter$1.run(ExecuteActionsTaskExecuter.java:131)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:300)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:292)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:174)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:90)
	at org.gradle.internal.operations.DelegatingBuildOperationExecutor.run(DelegatingBuildOperationExecutor.java:31)
	at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeAction(ExecuteActionsTaskExecuter.java:120)
	at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:99)
	... 34 more

[tumbarumba]

The README.txt is there to give people a hint that the jar is deprecated, and you should update your dependencies. Is there any reason why you can't remove the hamcrest-core and hamcrest-library dependencies, and replace them with hamcrest-2.1.jar?

[bubenheimer]

The documentation says that both artifacts are required for compatibility with JUnit 4.12.

[tumbarumba]

It's a bit more subtle than that. Neither hamcrest-core or hamcrest-library contain any classes. All the classes have moved into hamcrest-2.1.jar. The only reason hamcrest-core and hamcrest-library exist is to help with the version conflict resolution when upgrading, and provide a transitive dependency on hamcrest-2.1.jar. However, if these jars are causing you problems, you can simply exclude them from your dependencies, and declare a direct dependency on hamcrest-2.1.jar.

[bubenheimer]

If I understand you correctly, you are saying that including hamcrest-core-2.1 and hamcrest-library-2.1 provides an automated version conflict resolution mechanism when using JUnit 4.12, and it is possible to achieve the same result by manually excluding specific dependencies in Gradle build files. Is that what you mean? It would seem appropriate to actually make the automated mechanism work, instead of suggesting how to not use it. Or blame D8 if you think it's defective and wait for a fix, but it would seem so much easier for everyone to remove the offending files from the jars; I don't know a lot of developers these days who crack open binary jars in their Gradle builds to look for usage instructions.

[tumbarumba]

The version conflict resolution mechanism is working, and correctly pulling in all the dependencies. However, you appear to be doing something with all the dependencies that breaks your build. There's a long stack trace above which seems to imply that the build is trying to merge all the dependant jars into a single file, and hence getting the conflict. Is that correct? What is the merge for? Can you avoid merging all the jars?

[bubenheimer]

The tool that is doing the merge is D8, it's a non-optional Android build tool. All Gradle builds of Android apps using hamcrest 2.1 and JUnit 4.12 with the suggested conflict resolution mechanism are bound to fail.

[tumbarumba]

I'm curious to see what this looks like. Can you point me towards and example?

[bubenheimer]

I believe you'd have to install a recent Android Studio version or the Android SDK to get this to work; that may be somewhat time-consuming.

[sf105]

How about we rename the README.txt to DEPRECATED.txt?

[sf105]

Of course, the amusing part is that we get no support or interest from Google who rely on our free effort.

[tumbarumba]

From what I understand, having the a file with the same name in both jars will always be a problem. I've just pushed a commit which will give the files different names, and hopefully resolve this issue (after the next release, of course)

[bubenheimer]

I built and tested a snapshot and can confirm that this change resolved the issue.

[tumbarumba]

Thanks for confirming, @bubenheimer. I've just updated the CHANGES.md, so I'll close this issue now.