> Because we're stating facts about what happened to the module, not
> expressing what to do with the graph. You can't say 'please replace', you
> can only say 'was replaced by'. So something like replacedBy('org:*') means:
> this module was replaced by every module with organisation 'org'.
What about a fact like this: "Module X was replaced by a bunch of
modules that match certain naming convention".
Anyhow, I'm fine with replacing with specific module id. All real use
cases I have now are happy with specific module replacement.
> When A is replaced by multiple modules B and C, then whenever we see A in
> the graph, we can only replace it by a compatible version of A or a
> compatible version of both B and C. We can't choose only B or only C. If we
> choose one we also have to include the other. So, if we have A and B in the
> graph, we have to end up with B and C in the result.
>
> Given this, when A is replaced by every module in organization 'org', then
> if we see A and org:B in the graph, then we have to end up with every the
> modules on 'org' in the result. Which is fine, if that's what you want,
> except we currently have no good way of knowing what all the modules of org
> are.
>
> Net result is that you can only call replacedBy() with a module id. If you
> want to replace something with all the modules in an organisation, you'll
> have to list them out in your rule - something has to, and it's your problem
> at the moment. We might at some later point add some way to make this more
> convenient.
>
>
>
> 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.
>
>
> There's only 2 things really:
>
> - Dependency declarations. These are the edges in the graph. Dependency
> resolve rules operate on these. These are just criteria to use to choose a
> particular component, nothing more. Currently this means (group, module,
> version-selector).
>
> - Component meta-data. The components are the nodes in the resolved graph.
> Component meta-data rules operate on these. This is just bunch of facts
> about the component, its dependencies, its history, what it conflicts with,
> what it is compatible with, and so on.
>
> The goal is to keep these separate, so we only state things about
> dependencies (the edges) in dependency resolve rules, and only state things
> about components in component meta-data rules, so that we can reuse the
> component meta data in places other than just resolving dependency edges.
>
>
> --
> 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
