- And I review code of the people working with Maven and I know where it stores the dependencies, so my first hope (in vain) was that Gradle copies what I need to common Maven repo. Nope.
Of course not, it is Gradle, not Maven.
There are several good reasons not to do that.
- I looked at size of the Gradle folder, and found it like over 8 Gb… kind of much more that I wanted (my .m2 folder is like 2.5 Gb now).
That’s because Gradle is much better than Maven in providing reproducible reliable builds and avoiding work. This means for example that a build defines the exact Gradle version to build it and when the one running the build is using the wrapper scripts as exepected, this exact Gradle version is used and the build cannot change behavior or break just becuase a different Gradle version is used to run it like with Maven. If you use the Maven wrapper (basically a copy of the concept from Gradle, you will also have multiple Maven versions in your .m2
directory). And it also means, that Gradle has much more caches and things in its GRADLE_USER_HOME
, so there is additional data in it than just the JARs.
Also maybe the Gradle builds you used had more and different dependencies than the Maven builds you used and thus have more data in it. In the GRADLE_USER_HOME
are also things you shouldn’t care to copy or actually shouldn’t copy because they are not relocatable. You should for example omit the daemon
directory, as it only contains daemon logs and lock files.
And from the caches, you should probably only copy over what is documented at Understanding dependency resolution, which should basically be the JARs you were after.
- I looked at the wrappers, and found there 6.3, 6.6.1, 6.9, 7.4, 7.4.2 … kind of more than I thought.
Well, if you run many different projects that all use different versions, you have the different distributions there (not wrappers).
Of course you can decide not to use the Gradle wrapper to run the builds, but any installed Gradle version, but that might easily break the build or cause unexpected behavior, sometimes sneaky.
- I copied some jars manually, but next came problem with the Gradle plugins… they seem not being shared between wrappers.
Of course they are. Well, the built-in plugins are built-in in each Gradle version of course.
But all 3rd party plugins are in the dependency cache like any other dependency and also reused across versions unless there are variants of the plugin optimized for different Gradle versions, but that is very seldomly the case in the wild.
- I run Windows Clonespy utility looking for the duplicates, and found in Gradle folder duplicate jars over 360Mb in size.
Well, you would need to tell which to get any sane recommendation.
But I guess those are the jars in the distributions and for those there is of course not deduplication.
The cached dependency jars will not be duplicates.
An ideal for me solution would be to force Gradle to store all jars to .m2 {I have read the documentation that Gradle don’t trust Maven, but again, I’m willing to take the risk}.
That would not be ideal. That would simply not work at all and will probably never be possible for various reasons.
The second part is that I’m looking for a solution to get all jar dependencies for a particular project in one folder (IntelliJ build system seems to be able to do that).
Well, the dependencies for all projects are in one folder, the cache explained above.
If you want separate for each project, you could configure different GRADLE_USER_HOME
for the different projects, then only the dependencies of that project land in the respective cache, but then you have even less deduplication, i. e. none cross-project.
If you want the dependencies for a project in one directory, you need to write a copy task that copies the dependencies into that directory, but what would that help? You would then also have to change the build to take the dependencies from there. And maintain those changes, … You certainly don’t want to do that, especially for foreign projects.
I wonder if Gradle has means for minimizing the footprint and getting all dependencies in one compact place.
As the GRADLE_USER_HOME
is not designed to be shared and relocated except for particular parts, I don’t think there is any option to minimize it.