我有一个相当简单的构建,以前在Maven中工作正常。当我将它移植到Gradle时,我可以看到jcommander-1.12.jar正在从传递依赖中被拉入(我想通过TestNG)。这超越了我对jcommander 1.35的明确依赖。
JCommander 1.12不支持我在1.35中依赖的一些注释和值。
我可以使用
之类的东西删除jcommander上的所有依赖项configurations {
all*.exclude group: 'com.beust', module: 'jcommander'
}
(见http://mrhaki.blogspot.com.au/2012/10/gradle-goodness-exclude-transitive.html)
那么我如何优先考虑对继承的显式依赖?
更新
这是gradle dependencyInsight --dependency jcommander
$ gradle.bat dependencyInsight --dependency jcommander
:dependencyInsight
com.beust:jcommander:1.35
\--- compile
有趣的是,它甚至根本没有列出jcommander 1.12 ......
答案 0 :(得分:0)
这是一种意想不到的行为。默认情况下,当Gradle检测到冲突时,它会与较新的依赖关系一起使用。尝试运行gradle dependencyInsight --dependency jcommander
以获取有关为何选择版本1.12的更多信息。
无论如何,您始终可以强制使用特定版本的依赖项。
configurations.all {
resolutionStrategy {
force 'com.beust:jcommander:1.35'
}
}
答案 1 :(得分:0)
我不知道为什么这是一个问题,但我找到了根本原因。
我实际上是将一个命令行应用程序移植到Gradle插件,这意味着我添加了以下行作为依赖项:
compile gradleApi()
compile localGroovy()
如果我用编译compile gradleApi()
替换"org.gradle:gradle-core:2.0"
,则会解析正确版本的JCommander。