On 5 Aug 2014, at 10:03 am, Lóránt Pintér <lorant.pin...@gmail.com> wrote:
> Hi,
>
> With eachDependency { … } it was not possible to replace an external
> dependency with a project dependency. Will this be possible with this
> notation?
Not initially, but that’s the eventual plan. It’s not quite so simple because
external -> project dependency replacement also need the task graph to be
modified, whereas external -> external replacement does not.
> It would be awesome if this was possible.
>
> --
> Lóránt
>
> On Monday 4 August 2014 at 11:30, Szczepan Faber wrote:
>
>> Thanks Daz for input! Is the implementation of version-selection rules
>> happening soon?
>>
>> It looks like that we're getting to consensus regarding the API:
>>
>> dependencies {
>> components {
>> modules(moduleSelectorNotation) { detailsObject ->
>> detailsObject.replacedBy(moduleSelectorNotation)
>> }
>> }
>> }
>>
>> 1. I'm curious if there is a plan to align dependency resolve rules
>> and version selection rules in some way?
>> 2. Do we want to use an existing imperative API
>> "dependencies.components.eachComponent" as a way to pass down the
>> 'replacedBy' declarations to the resolution algorithm? E.g.
>> declarative data 'dependencies.components.modules' would form one of
>> the 'eachComponent' rules behind the hood. Based on Adam's feedback, I
>> assume that we _don't_ want to do this.
>>
>> Cheers!
>>
>> On Sun, Aug 3, 2014 at 11:09 PM, Daz DeBoer
>> <darrell.deb...@gradleware.com> wrote:
>>>
>>>
>>>
>>> On Fri, Aug 1, 2014 at 5:18 AM, Szczepan Faber <szcze...@gmail.com> wrote:
>>>>
>>>>
>>>> b) I would add some higher level api that would use a). For example:
>>>>
>>>> dependencies {
>>>> components {
>>>>
>>>> modules("com.google.collections:google-collections").deprecatedBy("com.google.guava:guava")
>>>> //or replacedBy(), supersededBy()
>>>> }
>>>> }
>>>>
>>>> Thoughts?
>>>
>>> We're designing a similar DSL for targeting version-selection rules to a
>>> particular module or set of modules
>>> (https://github.com/gradle/gradle/blob/master/design-docs/component-metadata.md#story-build-script-targets-versionselection-rule-to-particular-module).
>>>
>>> I'm not sold on that DSL, but we do need a way to say "this block applies to
>>> _all_ modules".
>>>
>>> I guess we can either choose to use a string-based selector for choosing the
>>> modules that apply:
>>>
>>> dependencies {
>>> components/versions/some-other-rule-type {
>>> modules('*') {
>>> }
>>> modules('com.google.guava:*') {
>>> }
>>> modules('com.google.guava:guava') {
>>> }
>>> }
>>>
>>> Or use explicit parameters:
>>>
>>> dependencies {
>>> components/versions/some-other-rule-type {
>>> allModules {
>>> }
>>> group('com.google.guava') {
>>> }
>>> group('com.google.guave').name('guava') {
>>> }
>>> }
>>>
>>> I think I prefer the first approach. But we should definitely aim for
>>> consistency here.
>>> --
>>>
>>> Darrell (Daz) DeBoer
>>> http://www.gradleware.com
>>
>>
>>
>> --
>> Szczepan Faber
>> Core dev@gradle; Founder@mockito
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>> http://xircles.codehaus.org/manage_email
>
--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
CTO Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com
