> 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.
Ok. Can you elaborate why we can't replace something with 'myorg:*'?
I'm curious, why cannot I say that: please replace module A with any
module found in the graph that matches some spec?
> I'm definitely not sold on `modules('*') { }` being better than `all { }`
Sure, tell us what's your preference regarding the dsl.
> 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.
That would be nice. It's getting hard to grasp all kinds of rules
applicable in various parts of the model.
We also have a strategy that there are a bunch of 'listener'
interfaces that can be directly added to Gradle instance. It was
somewhat nice that a single method (Gradle.addListener) can be used
and documents the listeners for extending Gradle's behavior. Not sure
how this kind of strategy would have worked for all kinds of rules
that alter dependency resolution but nevertheless I wanted to share
this thought.
> 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.
To me, it makes sense the reuse an existing mechanism
("dependencies.components.eachComponent") + convenience DSL. However,
I need to think about it some more.
I did spike with eachComponent initially. I had some problem with the
fact that 'metadata.resolve()' needed to be executed earlier than
before. However, that was probably something manageable.
> 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
>
>
>
--
Szczepan Faber
Core dev@gradle; Founder@mockito
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
