On Dec 4, 2008, at 10:08 PM, Hans Dockter wrote:
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.
Now the release it ready. The rollback was due to missing changelogs
and missing chapters in the user's guide, as well as a missing JDK 1.4
version. It was not related to bugs in the binaries.
- Hans
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
--
Hans Dockter
Gradle Project lead
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
