Hi,
I adopt the knowledge about transitive dependency to our real life use case.
We have many WAR files which include two JARs. Both JARs are provided.
It only works if i define it like the following example. Look at the
difference between compile and providedCompile. That was unexpected
for
Mathias,
of course, two simple transitive flags (one on Configuration and another
on Dependency) won't allow you to model all conceivable cases. But that's
not the goal. The real question is if they allow you to model the cases that
are relevant in practice. Your last example looked very
Hi,
excuse me, that I was not clear.
A general remark: It helps if posts are formulated as clearly and explicitly
as possible. For example, your latest post raised the following questions in
my head:
- Why do you first say that the Jars are included in the War, and then use
providedCompile?
Your last example is a good candidate for a JIRA issue. Section 23.4 of the
user guide touches the subject, but the workaround described there won't
work for project dependencies.
--
Peter Niederwieser
Developer, Gradle
http://www.gradle.org
Trainer Consultant, Gradle Inc.
Hi Peter,
I tried it with the pair of parentheses, but the result was confusing.
There is a difference between Code 1 and Code 2.
Code 1:
dependencies {
compile (project(':MySubProject')) {
transitive = false
}
}
Code 2:
configurations {
compile.transitive = false
}
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
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')) {
Before devoting more time to this discussion, I'd like to hear a convincing
use case.
--
Peter Niederwieser
Developer, Gradle
http://www.gradle.org
Trainer Consultant, Gradle Inc.
http://www.gradle.biz
Founder, Spock Framework
http://spockframework.org
--
View this message in context:
Am 27.01.2011 19:23, schrieb Peter Niederwieser:
Before devoting more time to this discussion, I'd like to hear a convincing
use case.
I don't have a real use case for this example.
I'm learning gradle, writing examples and sometimes I find a bug or a
missing feature. And maybe this is a
On Thu, Jan 27, 2011 at 6:29 PM, Mathias Kalb mathias.k...@prodato.dewrote:
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
On Thu, Jan 27, 2011 at 10:07 PM, Hans Dockter h...@gradle.biz wrote:
On Thu, Jan 27, 2011 at 6:29 PM, Mathias Kalb mathias.k...@prodato.dewrote:
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
http://jira.codehaus.org/browse/GRADLE-1317 describes the problem (it's not
limited to transitive = false) and the workaround.
--
Peter Niederwieser
Developer, Gradle
http://www.gradle.org
Trainer Consultant, Gradle Inc.
http://www.gradle.biz
Founder, Spock Framework
http://spockframework.org
Hi Peter,
thank you. I know the mails from last week with the exclude problem.
But I didn't thought, that it is the same bug.
Should I add a comment to the JIRA issue with the transitive bug?
regards,
Mathias Kalb
Am 26.01.2011 18:52, schrieb Peter Niederwieser:
It's not an exclude or transitive bug. It's simply not possible to
configure a project dependency without adding a pair of parentheses. As such
it's not necessary to add a comment about transitive to the issue.
--
Peter Niederwieser
Developer, Gradle
http://www.gradle.org
Trainer Consultant,
14 matches
Mail list logo
