On 5 Aug 2014, at 7:29 pm, Szczepan Faber <szcze...@gmail.com> wrote:
>> 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?
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’.
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 organisation ‘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
