On Thu, Jan 27, 2011 at 6:29 PM, Mathias Kalb <[email protected]>wrote:
> Hi Peter,
>
> thank you for your explanation. I expected the behavior of the second case
> also for the first case.
>
> But now I have a question.
>
> If I have two compile project dependencies, how can I define the behavior
> of the second case?
>
> dependencies {
> compile (project(':J1')) {
> transitive = false
> }
> compile (project(':J2')) {
> transitive = true
> }
> }
>
>
Good point. Gradle is inconsistent here. We could argue that Ivy is being
the one that is inconsistent (which we use under the hood), but that
shouldn't be your problem :)
if <configuration>.transitive == true and <dependency>.transitive == false
things works as I would expect.
if <configuration>.transitive == false and <dependency>.transitive == true
things do not work as I would expect. The <dependency>.transitive value is
ignored. We are aware of that issue and will fix that in M2. I'm not sure if
there is a Jira for this.
Another reason for confusion is that we are using the ivy terminology which
says configurations extend each other. I think the term 'extend' is
misleading. No properties are inherited. The true relation is more of a
composite one. This is something we also want to model nicer in M2.
Cheers
Hans
> compile: J1, J2, dependencies of J2
> runtime, testRuntime, ...: J1, dependencies of J1, J2, dependencies of J2
>
> regards,
> Mathias Kalb
>
>
> Am 27.01.2011 16:15, schrieb Peter Niederwieser:
>
> The first case is clear. The project dependency added to the compile
>> configuration has transitive resolution disabled. This also affects
>> configurations extending from compile, because they see the very same
>> dependency (aliasing effect).
>>
>> In the second case, the question is what "compile.transitive = false"
>> should
>> mean to configurations extending from compile. The current behavior makes
>> sense to me. For example, if you want to be strict about compilation and
>> only put explicitly listed dependencies on the compile class path, you
>> might
>> nevertheless want transitive dependency resolution for the runtime class
>> path.
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>
