Hello Hans,
thank you very much for the detailed explanation. I'll use Gradle for my
project and I'm looking forward to version 0.5.
Kind regards
Benjamin
On Tue, Dec 2, 2008 at 5:26 PM, Hans Dockter <[EMAIL PROTECTED]> wrote:
>
> On Dec 1, 2008, at 10:12 PM, Benjamin Klum wrote:
>
> 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 :)
>>
>
> Here we go ;). From a Gradle perspective there are two kind of build
> dependencies between what you call development projects. One is a (build)
> runtime dependency. If you build Java projects, such a dependency is usually
> established because the build of one projects depends on build artifacts of
> another project. Those kind of dependencies are not modeled as a tree by
> Gradle, they form an acyclic graph. It is very important to note that the
> order in which the projects are build is different from the order of the
> project tree. As you have said, a build system should figure the build
> order, based on the runtime dependencies. And that is what Gradle does.
>
> But there is another kind of dependency. Those are configuration time
> dependencies. Here is were the notion of parent and child is used.
>
> Let's play with your example above. The dependencies you have described
> above are build runtime dependencies. Let's say you want to have some common
> manifest entries or define common dependencies (e.g. log4j, junit) for your
> development projects. None of the projects above look like a good parent for
> this. If you had only one distribution, the distribution might be a good
> parent, but this is not the case here. Somewhere your settings.gradle has to
> live. Lets say it lives in the same directory as the top level directory of
> your projects. That would constitute a hierarchical layout. You can (you
> don't need to) now add a build.gradle to this directory and do things like:
>
> subprojects {
> usePlugin('java')
> usePlugin('osgi') // Gradle 0.5 comes with an OSGi plugin for generating
> OSGi bundles :)
> manifest ...
> dependencies {
> testCompile ...
> }
> }
>
> The gradle build has two phases. One is the configuration, the other the
> execution. In this case it is important that the parent script is evaluated
> before the subproject scripts, as the subproject scripts may assume that the
> JavaPlugin has been applied. So we have a configuration order, which is by
> default from top to bottom (but it is configurable). Now let's assume you
> want to build an ueberdistribution. In this case the build runtime
> dependencies are opposite to the configuration time dependencies (something
> not possible with Maven).
>
> The whole topic is also covered in chapter 14 of the user's guide.
>
> - Hans
>
> --
> Hans Dockter
> Gradle Project lead
> http://www.gradle.org
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>
