On Aug 24, 2009, at 6:29 PM, Philip Crotwell wrote:
Hi
Is there a way to distinguish between multiproject dependencies and
remote jar dependencies? For example in
gradle/src/samples/java/multiproject/services/webservice
the dependencies look like:
dependencies {
compile project(':shared'),
'commons-collections:commons-collections:3...@jar',
'commons-io:commons-io:1.2', 'commons-lang:commons-lang:2...@jar'
compile project(path: ':api', configuration: 'spi')
runtime project(':api')
}
then the below copy fails if the api subproject has not yet been
built, which is not what you want if you are just trying to get all
remote dependencies downloaded so you can work "offline". Ideally I
suppose you would want to download all remote jar dependencies and
then run the "retrieveRuntimeLibs" task on any dependency projects.
......................
:: problems summary ::
:::: WARNINGS
module not found: org.gradle#api;1.0
I tryed something like:
task retrieveRuntimeLibs << {
copy {
from configurations.runtime.files {dep -> dep instanceof
ExternalDependency}
into 'runtimeLibs'
}
}
but didn't seem to make any difference.
Let's assume the api project would have a dependency on commons-
math-2.0 and commons-collection on commons-math-1.0. Let's further
assume those are the only dependencies of the runtime configuration.
It is a feature that configurations.runtime.files {dep -> dep
instanceof ExternalDependency} then would return: commons-collection
and commons-math-2.0. To provide this feature we need to know about
the module descriptor of the api project and all the other module
descriptors. The way Gradle establishes access to all those module
descriptors is by resolving all dependencies and then applying the
filter. Which means the api project needs to be build an published to
the internal Gradle repository of the build.
If you do:
gradle test
gradle retrieveRuntimeLibs
everything should work fine. Of course this is not the way you want to
work. There is already an issue to make Gradle smarter here by not
requiring the project to be build and still be able to access its
dependency module descriptor. For now there are two possible
workarounds:
task retrieveRuntimeLibs(dependsOn:
configurations.runtime.buildDependencies) { ... }
Now the api project is build and published to the internal repository
before the configuration is resolved. This is a viable option. In
particular with Gradle 0.8, as we will have implemented all the
optimizations that a build for a project that has already been build
and uploaded will be very fast.
Another alternative is to say:
task retrieveRuntimeLibs << { ... configurations.runtime.copyRecursive
{dep -> dep instanceof ExternalDependency}.files ... }
The possible problem with this approach it that it would return
commons-collection and commons-math-1.0 for the example from above.
As said, in the future your code above should work out of the box.
- Hans
--
Hans Dockter
Gradle Project Manager
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
