Gradle provides both configuration by convention and scripting. I try to stick with more on convention side before writing any custom task.
In my project we have 20+ sub-projects/modules. We also have few dedicated modules for sharing common test code. Each project has its own main sources (sources refer both java classes and any resource from resources folder) and test sources. It is very easy to make dependency between sub-project and they can inherit/share source and resources from main folder. But the dependency module cannot see the dependent’s test source or resources. I prefer this way since test should be sand boxed within the sub-project and this is how works in maven as well. As we add more sub-projects, our test code also grows and we need to refer some sub-project’s test resources instead of keep creating abstracted test sub-project. To achieve this we directly referred the test output directory in the sub-project. To explain in detail, assume that we have two project, projectA and projectB. The projectB test is depends on the projectA’s test output as given in the script below.
dependencies {
testCompile project(":projectA").sourceSets.test.output
}
My question, is a good practice? I am concerned on referencing the directory instead of sub-project. This is kind of physical dependency (output directory) than logical dependency (project). Does gradle have any plan on supporting in logical way something like
dependencies{
testCompile project(":projectA") {
includeResource: test
}
}