Just realized 0.5 is already there, great news!
On Thu, Dec 4, 2008 at 9:30 PM, Benjamin Klum <[EMAIL PROTECTED]>wrote:
> 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
>>
>>
>>
>
