On Mar 31, 2009, at 12:48 PM, Hans Dockter wrote:
On Mar 30, 2009, at 10:54 PM, Steve Appling wrote:
Hans Dockter wrote:
On Mar 30, 2009, at 2:13 PM, Steve Appling wrote:
Hans Dockter wrote:
Hi Steve,
On Mar 29, 2009, at 7:01 PM, Steve Appling wrote:
I am attempting to use a custom configuration to resolve the
artifacts from another project in a multi-project build as
follows:
In proj3 -
dependencies {
//... clipped normal compile dependencies.
// Including declaring a company internal maven repo ...
compile project(':proj1')
addConfiguration('signer')
signer project(':proj1')
signer project(':proj2')
}
// inside task
String path = dependencies.signer.asPath
This results in :
Execution failed for task ':proj3:sign'.
Cause: Not all dependencies could be resolved!
Gradle appears to be trying to resolve the artifact from proj1
using my company internal maven repo instead of from the jar it
created in the build directory of proj1.
These types of project dependencies work fine for the compile
configuration, but apparently the Java plugin is doing
something special to make this work. It doesn't work as I
expect for a custom configuration. What can I do to get this
to resolve to the project jars without going to the repo?
The problem is that resolve (or the asPath method in your case)
does not trigger the build of a dependent project. I assume that
you get the exception, because proj2 is not build and its jar is
not available. In 0.5 the solution to this is:
dependencies {
linkConfWithTask('signer', 'myTask')
}
createTask('myTask') {
String path = dependencies.signer.asPath
}
In 0.6 we provide a nicer solution for this scenario.
- Hans
Thanks, but I already have a compile dependency on :proj1, which
should make sure it is built (and I see that the artifact jar has
been generated). Also, I am using the current head revision
which no longer has the linkConfWithTask method on
DependencyManager. Do you have any other ideas?
Just to be sure. You have proj1and proj2 as dependencies. As I
understand you, Gradle is complaining about a missing proj1
dependency?
- Hans
In trying to create a simple sample of the problem, I think I have
figured it out.
The task proj3:myTask that was having problems depended only on the
resources task in proj3. I was expecting that since I had project
dependencies on proj1 and proj2 for my signer configuration, it
would force the generation of these artifacts. If I add task
dependencies such as myTask.dependsOn(':proj1:libs') as well, it
seems to work. Perhaps this is what linkConfWithTask accomplished
automatically.
How is the linkConfsWithTask functionality achieved now (since it
has been removed from DependencyManager in the head revision)?
createTask('myTask', dependsOn:
dependencies.signer.buildProjectDependencies) {
...
}
In trunk buildProjectDependencies has been renamed to buildDependencies.
- Hans
--
Hans Dockter
Gradle Project lead
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email