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') {}
}
}
I'm notoriously bad at coming up with nice DSL's so I'd be very happy with
alternative suggestions.
Gary will be working on this soon, so it would be good to come up with some
sort of consensus.
Daz
> }
> }
> }
>
> 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
> <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
>
>
>
>
--
Darrell (Daz) DeBoer
http://www.gradleware.com
