Hi Peter, thanks for the answer. It’s now clear to me what that sentence of the user guide says. However, I’d like to note that Gradle is great at handling these concept, but a bit of confusion can arise. This happens every time I want to add new configurations to my project to do something more complex. I’ll try to explain. When you declare:
dependencies {
compile group: ‘org.somegroup’, name: ‘somedependency’, version: ‘1.0’, configuration: ‘someConfiguration’ }
you are saying: my project depends on the configuration “someConfiguration” of “somedependency”. The sentence Davide cited just says that this type of dependency declaration is not allowed if “somedependency” comes from a Maven repository, because this does not have the concept of “configuration”, but just have a “default” one. So far so good. However, please note that “compile” is itself a configuration (brought on my Gradle project by the Java plugin). So that declaration is actually saying: my project configuration called “compile” contains a dependency on the “somedependency” module, for which in turn the “someConfiguration” must be taken. So a configuration for a project/module is both a way of exposing itself (you call it a “shape”) and a container of dependencies, which themselves in turn can be taken in shape or in another.
So, let’s go forth. Consider the following:
// the following is implicitly added by the Java plugin configurations {
compile }
dependencies {
compile project (’:anotherProject’) }
Here you are saying: my project has a “compile” configuration and this “compile” configuration contains a dependency on the “default” configuration of “anotherProject”.
The Java plugin translates these declaration into this: - my project shape/configuration called “archives” (? not default!) will expose a JAR with my project class files compiled using the dependencies declared its “compile” configuration - my project depends on the default configuration of anotherProject, that is: my project classpath is filled with the artifacts in the “archives” (? not default!) configuration of anotherProject but also with the transitive dependencies taken from the “compile” configuration of anotherProject - however, if you look at the dependencies of my project (using the dependencyInsight, the dependency report or alike), you’ll see that not only the “compile” configuration is crowded with the transitive artifacts coming from the “compile” configuration of anotherProject, but also my project “default” configuration is populated similarly (because it extends the “runtime” configuraiton which in turn extends the “compile” configuration)… At this point I have a big “?” in my head.
My project default configuration “contains” the dependencies in the “runtime” configuration", but when my project is required by another project in its default configuration, it is presented with the artifacts in its “archive” configuration plus the artifacts in its “compile” or “runtime” configurations depending on the type of dependency the other project declares on my project…
So one question would be: what is the “default” configuration of a Gradle project for? And why, when I declare a project dependency leaving the “default” configuration for that dependency, does Gradle actually use the artifacts of the “archives” configuration of that dependency?
That’s a bit confusing, I must admit. Especially when you try to use these concepts for your purposes, because it’s quite natural to define a configuration, with its own dependencies and its own artifacts, in a “linear” way:
configurations {
foo }
dependencies {
foo project (’:anotherProject’)
foo ‘groupid:somedependency:1.0’
}
task fooJarTask(Type: Jar) {
// assembles the artifacts for the foo configuration }
artifacts {
foo fooJarTask }
That is: the foo configuration is used to expose an artifact that is built using the dependencies declared for the foo configuration itself.
I would appreciate a lot if you had some advices/thoughts to make all of this more clear.