>I'd put the versionConflictStrategy property on Configuration, rather than
DependenciesHandler. I think conflict strategy is a per-resolve decision
(just like transitive is, for example). Currently, Configuration is the
place for per-resolve settings.
That makes perfects sense. I'll make it a public method on configuration and
remove from dependencies. I thought that the shorthand method at the
dependencies {} block would be nice DSL-wise as that's the place where you
configure versions but I'm not picky about it :)
Any feedback on the DSL? Below is kind of wordy:
configurations.compile.versionConflictStrategy =
VersionConflictStrategy.LATEST
Cheers!
On Fri, Sep 30, 2011 at 6:16 AM, Adam Murdoch
<[email protected]>wrote:
>
> On 30/09/2011, at 10:33 AM, [email protected] wrote:
>
> Branch: refs/heads/master
> Home: https://github.com/gradle/gradle
>
> Commit: d5d625f13cd4144908358950eab27ec1c7f15547
>
> https://github.com/gradle/gradle/commit/d5d625f13cd4144908358950eab27ec1c7f15547
> Author: Szczepan Faber <[email protected]>
> Date: 2011-09-29 (Thu, 29 Sep 2011)
>
> Changed paths:
> M
> subprojects/core-impl/src/main/groovy/org/gradle/api/internal/artifacts/ivyservice/moduleconverter/dependencies/IvyConfig.java
> M
> subprojects/core/src/main/groovy/org/gradle/api/internal/artifacts/configurations/DefaultConfiguration.java
> M
> subprojects/integ-test/src/integTest/groovy/org/gradle/integtests/resolve/VersionConflictResolutionIntegTest.groovy
>
> Log Message:
> -----------
> On the way to be able to implement custom conflict resolution strategies.
> Enabled the integration test (it has some hacks for now). Now the conflict
> strategy is configurable, for now on selected configurations.
>
>
> Commit: 7b9884158f28ce0126933588451c178fb869df31
>
> https://github.com/gradle/gradle/commit/7b9884158f28ce0126933588451c178fb869df31
> Author: Szczepan Faber <[email protected]>
> Date: 2011-09-29 (Thu, 29 Sep 2011)
>
> Changed paths:
> M
> subprojects/core-impl/src/main/groovy/org/gradle/api/internal/artifacts/ivyservice/DefaultIvyDependencyResolver.java
> M
> subprojects/core-impl/src/main/groovy/org/gradle/api/internal/artifacts/ivyservice/moduleconverter/dependencies/IvyConfig.java
> M
> subprojects/core/src/main/groovy/org/gradle/api/artifacts/dsl/DependencyHandler.java
> M
> subprojects/core/src/main/groovy/org/gradle/api/internal/artifacts/configurations/ConfigurationInternal.java
> M
> subprojects/core/src/main/groovy/org/gradle/api/internal/artifacts/dsl/dependencies/DefaultDependencyHandler.groovy
> M
> subprojects/integ-test/src/integTest/groovy/org/gradle/integtests/resolve/VersionConflictResolutionIntegTest.groovy
>
> Log Message:
> -----------
> First stab at custom conflict resolution strategies. Currently one can
> configure them in the dependencies section of the build.
>
>
> I'd put the versionConflictStrategy property on Configuration, rather than
> DependenciesHandler. I think conflict strategy is a per-resolve decision
> (just like transitive is, for example). Currently, Configuration is the
> place for per-resolve settings.
>
> I would get rid of the DependenciesHandler.setVersionConflictStrategy. If
> you want to use the same strategy for all resolution, use configurations.all
> { }.
>
> The longer term plan is:
> * Move the per-resolve settings from Configuration to
> ResolvableDependencies. (Configuration.getIncoming() currently returns the
> ResolvableDependencies for the Configuration).
> * Change DependenciesHandler into a NamedDomainObjectContainer of
> ResolvableDependencies. When you add a Configuration using the
> ConfigurationContainer, the Configuration's incoming ResolvableDependencies
> instance is also added to the DependenciesHandler. And probably vice-versa.
> * Deprecate using Configuration for incoming resolution.
> * After doing the same separation for outgoing artifacts, deprecate and
> remove Configuration.
>
> That is, all incoming dependencies and resolution settings will be
> available via the dependencies { } section. You would also use it to do
> things like copy(from: dependencies.compile) instead of copy(from:
> configurations.compile).
>
>
> --
> Adam Murdoch
> Gradle Co-founder
> http://www.gradle.org
> VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
> http://www.gradleware.com
>
>
--
Szczepan Faber
Principal engineer@gradleware
Lead@mockito
