Hello Adam, Are they Gradle projects, or do you want to use Gradle to coordinate Ant or > Maven builds? Out of curiosity, if they are all Gradle projects, what does > the multi-project support do or not do that means you can't use it to solve > your problem? >
let's assume they are Gradle projects. From what I've read in the user guide, multi-project builds require you to structure the member projects in a hierarchy. OK, in v0.4 sub projects may reside in arbitrary physical locations (hello Hans, I've just read your reply) but the relation between the projects still has to be a hierarchical one - a tree: A sub project S always has exactly one parent project P even if S does not have to reside within the directory of P. Is this correct? If not, the discussion is over :) But in case it's true, I'll describe a use case for which I think that a hierarchical project structure is unnecessarily restricting and redundant if you already have declared dependencies. Background: I'm about writing an application with plug-in support using OSGi. The application is divided into following modules at runtime: * One application core, which provides the main functionality and serves as plug-in host (technically it's an OSGi bundle that registers a service). * Several plug-ins. A plug-in adds functionality (technically an OSGi bundle that consumes the core service). * Several distributions. A distribution is a compilation of the application core with a specific set of plug-ins "preinstalled" (a distribution is also responsible for starting up the OSGi container). It makes sense to have this kind of modularization also at build time. In particular, I'd like each runtime module (a module can be the application core, a plug-in or a distribution) to correspond to exactly one development module. Assuming we've following concrete modules: * Application core * Plug-in 1 (depends on application core) * Plug-in 2 (depends on application core) * Plug-in 3 (depends on application core) * Distribution 1 (contains application core with plug-ins 1 and 2) * Distribution 2 (contains application core with plug-ins 1 and 3) Now I'd like to build like in the following scenario: 1. I check out the whole code base into a flat directory structure (distribution-one, application-core, plug-in-one, ...). 2. I modify the code of distribution 1 and trigger a clean build. Application core, plug-in 1 and plug-in 2 are automatically built before distribution 1 because distribution 1 depends on them. 3. I modify the code of distribution 2 and trigger a clean build. Application core, plug-in 1 and plug-in 3 are automatically built before distribution 2 because distribution 2 depends on them. Do you see? If I should declare a parent project for plug-in 1, which one should I take? Distribution 1 or distribution 2 - both qualify as parent projects. Why should I establish a hierarchy at all if it wouldn't correctly reflect the dependencies anyway? What I'm trying to say: Shouldn't it be enough to declare **dependencies** between modules in order to let a build system figure out a reasonable multi-project build order? Dependency declarations form a directed acyclic graph, a less-restricted data structure than a tree. So why should I put any effort into structuring projects into a tree if I've already declared the exact dependencies between them? I know, it's common to make project hierarchies (e.g. Maven modules) - but why? Maybe I'm just missing a simple but important point here ... if so, please give me a hint :) Kind regards Benjamin
