On 22 August 2014 at 1:09:05 am, Szczepan Faber ([email protected]) wrote:
Hey,
Currently, we don't detect a change to the configuration after it was
resolved, when the change happens within hierarchy. For example:
configurations {
foo
bar.extendsFrom foo
}
configurations.bar.resolve()
//add dependency to bar, via configuration hierarchy:
dependencies { foo "org.lib:1.0" }
Is this by design? I just came across a hard-to-debug problem related
to this. I would prefer if this scenario was better handled, perhaps
even by preventing the dependency addition. However, I may not see the
full picture.
Sometimes I wish that an explicit "resolve()" was required to get the
configuration resolved. Sometimes it's easy to trigger resolution
without even knowing.
In the new configuration approach this would be more explicit and we’d avoid
this problem. All transformations are captured as “functions” (tasks really,
but we have a name overloading problem), including dependency resolution. If
you need the end result files for your function you’d declare this and we’d do
the transform at the right time, similarly if you just need the resolved graph
without the actual files. Basically, the implicit/on-demand approach that we
use now goes away. This allows us to understand where the dependencies are
going to be used.
