On 6 Aug 2014, at 9:25 am, Daz DeBoer <darrell.deb...@gradleware.com> wrote:
>
>
>
> On Mon, Aug 4, 2014 at 10:16 PM, Adam Murdoch <adam.murd...@gradleware.com>
> wrote:
>
> On 4 Aug 2014, at 7:30 pm, Szczepan Faber <szcze...@gmail.com> 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)
>
> The argument to replacedBy() needs to be a module id, not a module selector -
> you can’t replace something with 'myorg:*’ because we have no idea what
> modules there are in ‘myorg’. At least, we don’t yet.
>
> I’m definitely not sold on `modules(‘*’) { }` being better than `all { }`
>
> I think if we go with a notation-based approach for targeting a rule (which I
> like), then it would be good to be consistent.
> So option 1:
>
> dependencies {
> versionSelection {
> modules {} // For all modules
> modules('*') {} // Same as above
> modules('org:*') {}
> modules('org:my-module') {}
> }
> }
>
> And option 2:
>
> dependencies {
> versionSelection {
> all {}
> group('org') {}
> group('org').module('my-module') {}
> }
> }
There’s a slight semantic difference between the two options, not just syntax:
modules() { … } would implicitly match any component instance that is-a module
- that is something that comes from an ivy or maven repo, whereas all { … }
would match any component instance regardless of where it came from.
--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
CTO Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com
