On Sep 10, 2009, at 2:58 PM, Steve Appling wrote:
I noticed that gradle-core/build.gradle has dependencies declared in
multiple sections. There are 7 different compile declarations and 3
runtime ones. Are these intended to provide some meaningful
grouping of the dependencies that needs to be maintained or is this
something that can be cleaned up?
There are some dependencies (like ant) that are declared multiple
times. There are also dependencies that are in both the runtime and
compile configurations. If we try to maintain groups of
dependencies that logically go together, you are bound to get this
type of duplication. I don't know that this is bad, however.
I'll be glad to remove duplicates and create entries in the
libraries map for all these (so the versions can be maintained in
one place), but I wasn't sure what was desired here.
If you look at build.gradle before we have switched to the multi-
project build, you will find many module declarations, e.g.
compile module('...') {
dependency('...')
}
You need a separate compile configuration for every module declaration
(because of the closure). Modules allow us to define transitive
dependency relations without the need of an external module descriptor.
The problem is that modules don't work yet across projects (you can
only use them in single projects build at the moment). Of course this
is a bug. But I had no time yet to fix it. My temporary workaround was
to flatten the modules to normal dependencies. That is the reason for
the current untidyness and why some dependencies are declared multiple
times as first level dependencies. I want to work modules work in
multi-project builds soon. Therefore I think we might rather leave
this at it is.
- Hans
--
Hans Dockter
Gradle Project Manager
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
