Russel Winder wrote:
and it seems the build
requires multiple instances of mentioning them. Doesn't this violate
DRY and lead to maintenance nightmare?
Yes. Unfortunately, we don't have a good way to share module
definitions between projects yet.
Am I missing something, I had thought allprojects and subprojects were
closures that defined things for module sharing so as to support DRY.
[ . . . ]
True, we could use that.
Why should Gradle have to specify transitive dependencies of Groovy,
this is what Ivy should manage using the POMs. It seems highly
inappropriate for Gradle to have to track Groovy data.
We don't have to. But we choose to tightly control the meta-data for
the dependencies which end up in the distribution for a few reasons:
- We can restrict transitive dependencies to just those we need for
how we use the library. Given that we're using the public maven repos,
most poms tend to pull in more dependencies than they need. By
specifying this, we keep the distribution size down.
This is good.
- We can ensure we use a single version of each transitive dependency.
The public meta-data doesn't generally make use of version ranges, so
we get conflicts. This way we get to choose and make it explicit.
Conflicts are bad. :-)
- The above 2 combined mean we end up with less problems when we jam
everything into a single classloader.
- We can swap the implementation of a transitive dependency. For
example, we swap in jcl-over-slf4j for everything which depends on
commons-logging.
There is a cost to this, of course. So, we tend to use only module()
and @jar dependencies in the compile and runtime configurations, and
plain dependencies in the configurations that are used for testing and
building where the above issues don't matter so much.
This sounds like an example of an idiom of use that needs to be widely
known about. Is this in the user guide? If not then I think it
deserves a chapter. "Controlling transitive dependencies". It will
save everyone having to work out the idiom for themselves.
A good idea.
dependency(':commons-cli:1.0')
You can't have both 1.0 and 1.2 of Commons CLI? Anyway I thought Gradle
used JOpt Simple.
groovyc uses commons CLI. Gradle uses groovyc. That's why it's
declared as a transitive dependency.
My point was that both 1.0 and 1.2 are declared as dependencies, and
this is not good. I may be missing something though.
No, you're not. My mistake, I missed the two different versions in
there. I'll fix it up.
Adam
