There is a strong correlation between the parent and the path in the DefaultProjectDescriptor. In a case where you have a deep project hierarchy, this can produce some unwieldy project path identifiers. Given the following project directory layout :
±- app
±- webservices
|
±- 2013-01-13
|
|
±- api
|
|
– impl
|
– 2014-05-19
|
±- api
|
– impl
±- infrastructure
|
±- domainmodel
|
|
±- api
|
|
– impl
Gradle would attempt to provide me with project path identifiers like
:app:webservices:2014-05-19:api
and
:app:infrastructure:domainmodel:api
which nicely guarantees that my project path identifiers are unique. However, in terms of artifacts which must produce a unique GAV entry, I must control my name separate from my directory in terms of this directory structure.
In Maven, you must identify every project with a unique GAV (groupId, artifactId, version); therefore, you are you can reference a project simply by the artifactId in the context of a groupId (from the root project).
So if the project descriptor has distinct pieces of information (e.g., directory path, name, project path identifier, parent), why does it force all of those pieces to correlate?
Full disclosure: I’m trying to convert a brownfield Maven project to Gradle and trying to decide how much restructuring of this project is necessary with Gradle.
It appears that the DefaultProjectDescriptor maintains the name and the path based upon how descriptor was constructed. In the example above,
include ‘:app:webservices:2014-05-19:api’
would produce a descriptor with the name ‘api’ and the path id ‘:app:webservices:2014-05-19:api’. You must use the path id in order to reference the project through out the build scripts even if the name is guaranteed to be unique (e.g., I cannot reference it simply by the leaf portion of the path).
I’m trying to migrate a project from Maven to Gradle. If I use the Maven artifact id for the name, some of the path become cumbersome to use. For example,
I think the Gradle model works well when the subprojects are in a flattened directory structure as in the case of Gradle, Groovy and Spring. However, in a deeper hierarchy like the one I have it becomes cumbersome to use the path id.
Groovy seems very flexible to me, but the DefaultProjectDescriptor seems rather rigid. I was hoping for some insight into why the construction and properties of the DefaultProjectDescriptor was so inflexible.
If you don’t want a deep logical structure (which, as I said, is totally independent from the directory structure), then use a flatter one, which will result in shorter paths. As your Maven artifact IDs will likely be unique within the build, you could even use a completely flat logical structure. Also, Gradle APIs do accept relative project paths, which are interpreted as relative to the current project.