Is it necessary or correct to refer to the top-level project as ':' to make it available as a compile-time dependency to subprojects


(JG Homan) #1

I’m trying to build a nested project laid out ala http://pastebin.com/VzKDHGtF .

I need the subproject to be a separate artifact that depends on the main project. The settings.gradle file’s entire content is “include ‘someconnectors’” and the actual build.gradle for both the main project and subproject are completely standard java. The main project does not list the subproject as a dependency and only references it via settings.gradle.

However, I was initially unable to get the subproject (someconnectors) to compile (via gradle jar from the top-level project) as it cannot find the classes from the main project (which I’ve verified were compiled and are present in the top-level build directory. After quite a bit of searching, I was able to get it to compile by including: > compile project(’:’)

into the subproject’s dependencies, but am quite surprised that this is necessary.

Are the main project’s artifacts not put on the subproject’s classpath by default? Is this the correct syntax for doing what I’m trying to accomplish? There’s little documentation on this as the examples and O’Reilly book assume one is trying to do the opposite, ie get the main project to depend on the subprojects.


(Peter Niederwieser) #2

Yes, ‘compile project(’:’)’ is correct. Gradle doesn’t make any assumptions about which projects have artifact dependencies on which other projects. That’s why you have to declare them. The project hierarchy is a separate concern and doesn’t play into this.

Personally I prefer to put code only into leaf projects. I find that easier to understand and work with because no hierarchy gets in the way. But Gradle doesn’t care.