subprojects { } mixup?
|
View:
New views
3 Messages
—
Rating Filter:
Alert me
|
 |
subprojects { } mixup?
by Steven Devijver-3
::
Rate this Message:
Some parts of this message have been removed.
Learn more about Nabble's security policy.
Hey, I'm using the latest Gradle HEAD and I'm experiencing an unexpected behavior with the subprojects { } method: subprojects { if (name.startsWith('spring-')) { assert name == "spring-core" configurations {
moduleJars sources archives } dependencies { moduleJars project('java14') moduleJars project('java15') } task files << { configurations.moduleJars.files.each { file -> println file.name
} }
task moduleJar(type: Jar) { destinationDir = file('build/jar_for_module') } artifacts { archives moduleJar } task uploadArchives(type: Upload) { dependsOn moduleJar
configuration = configurations.archives repositories { flatDir(dirs: dist_dir) } } moduleJar.doFirst { assert configurations.ivyService.ivyService.ivyService.metaDataProvider.module.name == "spring-core" for (jar in configurations.moduleJars.files) { moduleJar.merge(jar) } } } } The second assert (the one in the moduleJar task) fails while the first assert works. Is this as expected? I got the same result with Gradle 0.8. I've added these asserts because configurations.moduleJars is throwing an expection saying the moduleJars property is not found. I've uploaded the entire project for download here: Thanks for your help Steven |
|
|
Re: subprojects { } mixup?
by Adam Murdoch-2
::
Rate this Message:
Some parts of this message have been removed.
Learn more about Nabble's security policy.
Steven Devijver wrote:
This problem comes about whenever you have a closure inside subprojects { } which is not executed straight away. For example, the task action closures above do not execute until the task executes. By the time the task action closure executed, the delegate of the subprojects {} closure is no longer pointing to the task's project, instead it points to the last subproject. This means that property and method references in the closures will be executed against the last subproject, rather than the task's project. Could you add a JIRA issue for this problem? A work around is to do something like: moduleJar.doFirst { task -> for (jar in task.project.configurations.moduleJars.files) { .... } }
-- Adam Murdoch Gradle Developer http://www.gradle.org |
|
|
Re : [gradle-user] subprojects { } mixup?
by Steven Devijver-3
::
Rate this Message:
Some parts of this message have been removed.
Learn more about Nabble's security policy.
Hey Adam, Thanks for the reply. Steven De : Adam Murdoch <a@...> À : user@... Envoyé le : Ven 16 Octobre 2009, 8 h 38 min 41 s Objet : Re: [gradle-user] subprojects { } mixup? Steven Devijver wrote:
This problem comes about whenever you have a closure inside subprojects { } which is not executed straight away. For example, the task action closures above do not execute until the task executes. By the time the task action closure executed, the delegate of the subprojects {} closure is no longer pointing to the task's project, instead it points to the last subproject. This means that property and method references in the closures will be executed against the last subproject, rather than the task's project. Could you add a JIRA issue for this problem? A work around is to do something like: moduleJar.doFirst { task -> for (jar in task.project.configurations.moduleJars.files) { .... } }
-- Adam Murdoch Gradle Developer http://www.gradle.org |
| Free embeddable forum powered by Nabble | Forum Help |
