the gradle version being used 7.6.1
OS tested in → windows 11 and macos Ventura (13.5)
Execution failed for task ‘:app:processResources’.
Entry testingFile.txt is a duplicate but no duplicate handling strategy has been set. Please refer to Copy - Gradle DSL Version 7.6.1 for details.
How to recreate the issue:
Create a gradle application project,
implementation language : java
split functionality: no
build script: groovy dsl
test framework: junit jupiter
add the following lines into the build.gradle file
What I think the issue could be
- Commenting out the srcDir in sourceSets makes the build work, and the jar file generated contains all the required files, so may be the conflict is due to the processResource task of jar and processResource task of sourceSets
I am able to solve the issue by setting the duplicateStrategy to “exclude” but would like to know what the root cause of the issue.
Another weird thing about this is that the issue occurs only in windows OS but not in macOS.
Any help or pointers on why this issue is occurring and specifically in windows would be helpful
Not having tried to reproduce, but mainly guessing right now.
This is most probably not a win vs. mac issue.
And you are correct in better not setting a duplicate strategy, this is in almost all cases just symptom treatment, and you better fix the cause.
When I have seen this happen in the past was, when an IDE was configured to also compile into the classes output directory (e.g.
build/classes/java/main), because the IDE does not only compile the classes to there but also copies the resources into the same directory. And if you then later kick off the Gradle build, it finds the resources in
src/main/resources and thus complains about duplicate file.
If this is also the reason here, you should either change the IDE so that it delegates building to Gradle, or configure a separate output directory that does not pollute Gradle task output directories, e.g.
srcDir 'src/main/resources' you have should not have any effect at all, as that is already the default configuration. That commenting it out makes it work is most probably just a coincidence.
due to the processResource task of jar and processResource task of sourceSets
There is only one
processResources task that is created for the
main source set and the result of which is packaged into the
Thanks Kautler for sharing your thoughts
In the above situation, I am executing the below commands on the terminal(powershell in windows context) so IDE should not be the cause of the issue.
I use intellij idea for the purpose editing and reading the code. To be sure, I have created the sample project for the reproduction through terminal and edited the build.gradle through notepad, Based on this I believe Intellij is not causing any issue atleast in this situation.
On side note, I have remove all other code blocks except the sourceSets in the build.gradle of the sample project and the above build failure persists. I believe there is an issue in how I am using sourceSets in the context of windows.
I tried using gradlew and gradlew.bat for checking if the issue might be due to incorrect gradle installation in windows, the issue does not seem to be due to gradle installation issue.
Hm, it indeed reproduces here too.
Must have misremembered about the
srcDir 'src/main/resources' being a no-op.
But then I think there should be no difference between Windows and macOS.
The only thing I could imagine is because you are not using the Gradle wrapper to run the build as you said.
You should never use any installed Gradle version anywhere to run a task, unless the project you want to build misses the wrapper files and that imho is a build bug of that project.
You should always use the Gradle wrapper to run a build and then it should also behave the same consistently as the Gradle wrapper defines and controls the Gradle version used to run a build.
Anyway, as I said,
src/main/resources is the conventional default anyway, so just remove that whole
sourceSets block and the build will behave as you intended.
I have tried using the gradle wrapper too that comes with project, the issue persists in windows, but not in macos. For now since it is a default I will comment out that part of the code.
I will try with gradle 7.6.3 if this is an issue specific to this gradle 7.6.1
It is not, I also tried with 8.4
Why it behaves differently between win and mac would need some debugging.
Maybe it is worth an issue report, they should really behave the same on both I think.
should I be raising a issue report here Issues · gradle/gradle · GitHub? sorry for the noob question
Yes, that’s exactly the place to report errors