When generating a distribution, I get an error message: Duplicates detected, and no duplicate handle strategy set. I’m not sure as you can reproduce it by yourself, but the project is here:
As far I know, there are several ways like include or exclude files, but I think to simply overwrite would be best. It is not a large project, I’m usually not interested in historic build artifacts, and I’m not interested to have a copy of such things.
I’m not sure what duplicate exactly means: a file with the same path and name, or a file with the same content, but in both cases, as far I understand everything right it would like to overwrite the old waste.
Can you share a build --scan URL of your problem?
I don’t see why that project should get a duplicates problem somewhere.
Generally a duplicates problem means, that some file path is occuring twice, the contents are irrelevant, even with the same content you get an error.
And in almost all cases trying to resolve the duplicates situation by setting a duplicates strategy is the majorly wrong thing to do.
In almost all cases it points at something else being wrong and causing the duplicate situation in the first place, and that is the problem that should be fixed, so that not duplicates are happening anymore.
Here is the result of a build --scan command url, including the whole shell report:
BUILD FAILED in 4s
PS C:\Path\To\Simple Russian Typing Trainer> ./gradlew build --scan
Task :Simple Russian Typing Trainer:distTar FAILED
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':Simple Russian Typing Trainer:distTar'.
Entry Russian Typing Trainer Windows-1.1.0/lib/About.html is a duplicate but no duplicate handling strategy has been set. Please refer to https://docs.gradle.org/8.3/dsl/>org.gradle.api.tasks.Copy.html#org.gradle.api.tasks.Copy:duplicatesStrategy for details.
* Try:
Run with --stacktrace option to get the stack trace.
Run with --info or --debug option to get more log output.
Get more help at https://help.gradle.org.
BUILD FAILED in 11s
5 actionable tasks: 1 executed, 4 up-to-date
Publishing a build scan to scans.gradle.com requires accepting the Gradle Terms of Service defined at https://gradle.com/terms-of-service. Do you accept these terms? [yes, no] y
Please enter 'yes' or 'no': yes
Gradle Terms of Service accepted.
Publishing build scan...
https://gradle.com/s/kh572ssc3mtt2
PS C:\Path\To\Simple Russian Typing Trainer>
Ah, it would have helped if you mentioned that you are not using the master branch that you linked to, but a totally different branch. There the problem is pretty obvious and actually multi-fold in your case.
You should never use files or fileTree for dependencies, that is bad practice and will always make problems, it for example is also not properly visible in dependency report tasks or build scan. Best is, if you never use any local file dependencies, and not have them in VCS, so just depend on com.sibvisions.jvx:jvxserver:3.1 and com.sibvisions.jvx:jvxclient:3.1. If you really need local file dependencies for example a library is nowhere downloadable (with an Ivy repository configured you can download a dependency from any URL), then at least use a flatDir repository and “normal” dependency declarations, but never files or fileTree.
In addition to the general fileTree usage for the dependency, you depend on each and every file (not only .jar files), and also on each and every file in the JavaDocs of that library which makes even less sense. In the JavaDocs you have libs/jvx-3.1_javadoc/api/com/sibvisions/rad/application/About.html and libs/jvx-3.1_javadoc/api/com/sibvisions/rad/application/class-use/About.html and you depend on those files so they are added to your classpath. All these files are tried to be packaged to the lib directory in your distribution which then of course clashes as there are two files with name About.html that should be put there which is the actual problem.
So as I said, best is, remove those fileTree dependencies, delete those binaries from your VCS, and use proper dependencies instead and your problem will be gone.
Crap…I tried to grab JVx dependency from repository, but failed with that. Something was always missing, and my current implementation worked nice for development. I need only one class and some methods from other files, so I avoided to grab all the server-client-stuff.
Ok, I will see how I can wipe the use of fileTree out. Thanks for your good explanation.
and it just works.
If you only need one, or want to exclude dependencies, well, that’s your decision, but I don’t see how you could “miss” something.
That’s one of the main points of a proper build tool, that it manages your dependencies and their transitive dependencies.
Indeed…it works with that. Its also still working if you exclude the server dependencies und grabs the jvxclient only.
I followed the link from JVx sourceforge project, but need to re-search the jvx stuff manually because the link itself is not working.
There was much more than these both links only. If you are on the JVx sourceforge site on the files list, I only need the “JVx + SwingUI” folder (and only one class and some little other stuff from there).
But on the sonatype repo collection, I found nothing similar enough refering to any UI-like stuff. The version numbering seemed also odd to me, even though the jvxclient repo ends at 3.0 instead of 3.1. Just why I missed this.
How did you found that so quick? Or does any sibvisions library contains the JVx+Swing-libraries…? I do not know the JVx-framework well, it was just a hint from another forum. (There, I say often that I’m not a programmer…)
Nevertheless, thank you for your gentle help. As it works no fine, I think I can publish the next release this weekend.
The version numbering seemed also odd to me, even though the jvxclient repo ends at 3.0 instead of 3.1. Just why I missed this.
Well, the place you search is not meant for this.
Most probably they migrated from the old Nexus-based OSSRH publishing where you search to the new Publisher Portal that everyone has to migrate to before end of June, so you do not find 3.1 or later on OSSRH.
After that, I get to the mess I described before. The idea to use JVx was not my own, I get this hint from another guy in another forum. I asked him how he managed to include it in gradle, and he told me he has just use the downloaded files local. And so I did how I did.
Thanks for sharing the idea to search direct by a used class…very good idea, I strongly need to remember that.
The link is working, it just does not allow directory listing.
It is the Repository URL that you would use maven("<here>") in Gradle when you want to use a snapshot version.
Their whole documentation and website is just - well - sub-optimal.
