On Dec 4, 2008, at 9:35 PM, Benjamin Klum wrote:
Just realized 0.5 is already there, great news!
We had to roll it back. I have hoped nobody has noticed. In half an
hour things should be allright and 0.5 can be used.
Apologies
- Hans
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
--
Hans Dockter
Gradle Project lead
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
