Thanks everyone for feedback. I conclude that the incubating API for now can be:
dependencies {
components {
module(moduleSelectorNotation).replacedBy(moduleNotation)
module(moduleSelectorNotation) {
replacedBy(... moduleNotation)
setReplacedBy(... moduleNotation)
}
}
}
1. Initially, both moduleSelectorNotation and moduleNotation will
support the same inputs:
- String like "com.google.collections:google-collections"
- ModuleIdentifier instance
- Map with group and name
2. replacedBy() appends new replacement target. There can be multiple
targets because a module can be replaced by a set of modules.
3. replacedBy() accepts var args, e.g: replacedBy("org:foo1", "org:foo2")
4. setReplacedBy() replaces the currently set replacement target
Cheers!
On Wed, Aug 6, 2014 at 3:14 AM, Adam Murdoch
<[email protected]> wrote:
>
> On 6 Aug 2014, at 9:25 am, Daz DeBoer <[email protected]> wrote:
>
>
>
>
> On Mon, Aug 4, 2014 at 10:16 PM, Adam Murdoch <[email protected]>
> wrote:
>>
>>
>> On 4 Aug 2014, at 7:30 pm, Szczepan Faber <[email protected]> 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
>
>
>
--
Szczepan Faber
Core dev@gradle; Founder@mockito
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
