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 { }`
> }
> }
> }
>
> 1. I'm curious if there is a plan to align dependency resolve rules
> and version selection rules in some way?
Yes. Whatever pattern we use to target things for the component rules, we
should use the same pattern for the other things.
> 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.
I think it’s still an open question as to whether we use the component
(instance) meta-data rules or introduce a new type of meta data for streams of
work and how they map to modules over time.
If we decide to add this to component meta-data then we would use whatever DSL
happens to be available for defining the component meta-data, which happens to
be `dependencies.components.eachComponent`. We’d later add the modules(_) { … }
convenience DSL.
>
> 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
>
>
--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
CTO Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com
