Excludes DSL needs some improvements (error on unknown keys, error if no valid keys)


(Luke Daley) #1

There are several problems with the dependency excludes DSL. I’m talking about…

configurations {
  compile ("foo:bar:1.0") {
    exclude «stuff here»
  }
}

One problem is that ‘exclude [:]’ is effectively ‘exclude module: “", group: "”’. This gets worse when people get one of the keys wrong, ‘exclude name: “baz”’, as this will just silently exclude everything.

Another is that ‘module’ is probably the wrong key to be looking for, it should probably be ‘name’.

We should also fail early if a key is used that we don’t support, and internally this should use the notation parser mechanism.


(Szczepan Faber) #2

Seconded. This is a reoccurring problem as we use maps in other places, too.


(Peter Niederwieser) #3

Another is that module is probably the wrong key to be looking for, it should probably be name.

Some time ago I wrote about this on the mailing list, and the outcome was that we should use module everywhere. However I haven’t acted on it yet because I feared it would be a major breaking change.


(Adam Murdoch) #4

We would deprecate ‘name’, and start supporting ‘module’.


(Luke Daley) #5

So that includes deprecating Dependency.getName() ?


(Adam Murdoch) #6

Right. Dependency.getName() doesn’t really convey the meaning. A dependency doesn’t have a name. It has a set of (group, module, version, configuration) patterns that are used to select a matching configuration.

We might think about pushing getGroup(), getModule(), and getVersion() down to ModuleDependency, too, while we’re changing things.