On Mar 3, 2009, at 5:16 PM, Allan Lewis wrote:
Thanks - I'll give your suggestion a try. Is this something that
will be
fixed? Is there a JIRA I can keep my eye on?
There is an issue for this: http://jira.codehaus.org/browse/
GRADLE-296. There are some implications I ran into when I did try to
change this. I can't remember what this was right now. So it is still
something we need to discuss.
- Hans
Adam Murdoch-2 wrote:
Interesting. When a task action closure executes, we set its (groovy)
resolve strategy to OWNER_FIRST. In your example, the owner is the
subprojects { } closure. This closure has its resolve strategy set to
DELEGATE_FIRST, and the delegate will be set to the last project
configured, ie project 'subB'. What this means is that whenever the
task
action closure executes, 'project.name' will be resolved against
project
'subB', regardless of which project the executing task is actually
in.
We should probably be using DELEGATE_FIRST as the resolve strategy
for
task actions. Until we fix this, you can use something like:
subprojects {
...
createTask('generateSources') {
logger.error('My name is: ' + *delegate*.project.name)
}
}
--
View this message in context:
http://www.nabble.com/Multi-project-build-question-tp22302724p22311865.html
Sent from the gradle-user mailing list archive at Nabble.com.
---------------------------------------------------------------------
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
