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
<[email protected]> wrote:
>
>
>
> On Fri, Aug 1, 2014 at 5:18 AM, Szczepan Faber <[email protected]> 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
