我的gradle配置在构建期间没有使用正确的类路径

我有一个多项目设置（ProjectB - > ProjectA），我使用flatDir在每个项目中指定一个lib目录。我的gradle配置在构建期间没有使用正确的类路径

项目A：

repositories { 
    flatDir name: 'localRepository', dirs: 'lib' 
} 

dependencies { 
    compile group: 'com.google.guava', name: 'guava', version: 'r08' 
    compile group: 'com.miglayout', name: 'miglayout', version: '3.7.4' 
    testCompile group: 'junit', name: 'junit', version: '4.+' 
    testCompile group: 'org.easymock', name: 'easymock', version: '2.5.2' 
}

项目B：

repositories { 
    flatDir name: 'localRepository', dirs: 'lib' 
} 

dependencies { 
    compile group: 'yan', name: 'yan', version: '5.0.2' 
    runtime group: 'yan', name: 'jfunutil', version: '5.0.2' 
    compile project(':ProjectA') 
    testCompile group: 'junit', name: 'junit', version: '4.+' 
    testCompile group: 'org.easymock', name: 'easymock', version: '2.5.2'

}

当我使用gradle dependencies为项目B，将产生正确的依存列表，示出传递依赖从项目A（例如，包括番石榴-R08）。但是，如果为gradle build，则用于javac的实际类路径只包含ProjectB的直接依赖项以及构建ProjectA生成的jar。

另一个烦恼是它似乎为testCompile，我不得不重新声明依赖项目B的junit，否则gradle dependencies将不会成功。

任何指针非常赞赏 - 我是新来的Gradle。

来源

2011-05-16 zorgbargle

关于你的项目结构...

这似乎是一个更好的主意，有，而不必为每个项目一个lib文件夹。

你的目录结构是这样的：

project/settings.gradle 
project/ProjectA/lib 
project/ProjectA/src 
project/ProjectB/lib 
project/ProjectB/src

你为什么要为每个子项目一个lib文件夹中有什么特别的原因吗？这似乎是一个更好的主意：

project/settings.gradle 
project/lib 
project/ProjectA/src 
project/ProjectB/src

可以创建项目（项目/的build.gradle）的根目录中的build.gradle包含以下内容：

subprojects{ 
    apply plugin: 'java' 
    repositories { 
     flatDir name: 'localRepository', dirs: "$rootProject.projectDir/lib" 
    } 
}

这种方式可以把你所有的依赖关系放到project/lib中。

关于你的测试depencendies ...

您也可以将您的testCompile依赖这个根的build.gradle文件。它变为：

subprojects{ 
    apply plugin: 'java' 
    repositories { 
     flatDir name: 'localRepository', dirs: "$rootProject.projectDir/lib" 
    } 
    dependencies{ 
     testCompile group: 'junit', name: 'junit', version: '4.+' 
     testCompile group: 'org.easymock', name: 'easymock', version: '2.5.2' 
    } 
}

这样你就不必指定每个子项目的的build.gradle文件testCompile依赖。

然而，当我摇篮建立，用于为javac 实际classpath中只包括项目B的直接依赖，并通过建设项目A产生的罐子。

为了编译ProjectB，你只需要ProjectA。只有ProjectA是你的编译依赖; ProjectA编译依赖项成为ProjectB的传递依赖项。

来源

2011-05-17 01:01:54

感谢您的建议，但也许我简化了太多的东西。这个想法是ProjectA是一个通用库。它包含我的常用工具等，并且我有3个其他项目（应用程序）依赖于ProjectA。项目A应完全独立于其他项目，另外项目（项目B，C，D）彼此独立。这就是为什么我不那么热衷于全球网络概念以及分层次的项目结构。（尽管我并未完全否认这一点 - 所以非常感谢你的努力！） – zorgbargle 2011-05-17 18:22:33

我同意上一个答案。多次尝试后，我们有相同的结构

> shared 
- build.gradle 
- gradle.properties 
- settings.gradle 
> project-a 
- gradle.properties 
- settings.gradle 
> project-b 
- gradle.properties 
- settings.gradle

共享具有所有共同的代码，在我们的情况下，它处理签到，模块部署，代码质量（的Cobertura），编译等共享还定义了类路径，其是由子项目继承，然后可以添加其他依赖项。

对于您的问题：

你有没有定义在项目中的以下？

settings.gradle includeFlat（ '项目B'）

你有没有定义在项目B以下？

settings.gradle includeFlat（ 'A计划'）

来源

2011-05-19 12:29:16

这看起来与以前的答案略有不同：在上一个答案中，似乎共享lib文件夹是在根项目中定义的，而ProjectA和ProjectB是根的子项目。在你的情况下，它看起来像共享是项目a和项目b的兄弟姐妹。我的偏好是这样一个扁平的层次结构。考虑我是否共享a和共享b（两个独立的核心项目可供应用级项目使用，请问您的解决方案是否支持这种结构？谢谢！ – zorgbargle 2011-05-23 20:45:58

是的，这就是我们如何使用它，如果你愿意，我会发布更多的细节，但我想你现在可能已经弄清楚了，我只是做了一个非常简单的项目，并得到了结构的工作，然后我添加了所有真正的代码。我发现与Gradle的问题是文档不是足够成熟，你永远不知道哪个是最好的办法。我希望这不是一个由于学习资源不足而消失的项目。 – 2011-05-25 09:48:49

谢谢，仍然卡住了：我尝试过项目B：includeFlat（'Project A'）。因为B依赖于A，所以我不希望为A使用includeFlat（'B项'）（A不应该知道B的任何内容）。我的构建现在在执行Gradle构建时失败了 - Gradle确定它必须先构建A（是），但随后尝试解决A对B的lib文件夹的jar依赖关系（不！），因此它找不到任何Jar和项目A获胜不会编译。这很令人沮丧，因为它看起来像你的结构正是我所追求的 - 谢谢！ – zorgbargle 2011-05-30 21:05:23

在原岗位的构建脚本都很好。传递性依赖解析不起作用的原因是项目只会使用自己的存储库来解析其配置。因此，解决您的问题的一种方法是只有一个lib目录。另一个解决方案是为B声明第二个存储库，指向A的lib目录。

另一个烦恼是它似乎为testCompile，我不得不重新声明依赖于ProjectB的junit，否则gradle依赖将不会成功。

不知道你在这里说什么，但它可能是我上面解释的结果。也许下面的信息也有帮助：根据项目不会拉动它的testCompile/testRuntime依赖关系。预计您必须为每个需要它的项目声明JUnit。为了避免重复，您可以使用configuration injection来声明项目之间的共同点。以前的答案已经给出了具体的例子（例如subprojects { ... }）。

来源

2012-05-17 10:07:22

我的gradle配置在构建期间没有使用正确的类路径

回答

相关问题