On Mon, Aug 16, 2010 at 2:31 AM, Adam Murdoch <[email protected]> wrote:
> On 15/08/10 10:31 PM, Matthias Bohlen wrote: > >> Hi, >> >> I filed a Jira issue today because so many things go wrong with my gradle >> build: http://jira.codehaus.org/browse/GRADLE-1118 >> >> What shall I do? >> > > Here's what I did to get your build working. > > The problems come down to doing some things at configuration time that need > to be done at execution time. There's some more detail about this > distinction in the user guide (hidden at the back, so it's quite reasonable > if you missed it): > http://gradle.org/0.9-rc-1/docs/userguide/build_lifecycle.html > > 1. Add the attributes to the jar manifest at execution time, rather than at > configuration time: > > jar.doFirst { // <- note the doFirst > manifest { > attributes( > "Main-Class": "com.somecompany.SomeApplication", > "Class-Path": configurations.executableJar.collect { File file > -> file.name }.sort().join(' ') > ) > } > } > > You need to defer querying the contents of the executableJar configuration > until after projectB has been configured. This is because if you query it > before then, the configuration won't contain the jar (as you're seeing). > Plus, configurations cache their contents, so if you query it before > projectB has been configured, it will never contain the jar. > Deferring is easy. Attribute values can be any kind of object. So you can use a Groovy GString: "Class-Path": "${ -> configurations.executableJar.collect { File file -> file.name }.sort().join(' ')}" > 2. Configure the clientZip at configuration time rather than at execution > time (but don't print the contents of the configuration): > > task clientZip(type: Zip, dependsOn: [jar, configurations.executableJar]) { > // <- note no << > from jar.archivePath > from configurations.executableJar > } > > Most typed tasks like Zip have a short-circuit check which skips the task > if it has not been configured to contain any files. This runs before the > actions of the task (ie before the code in << {...} run). You were hitting > this short-circuit check. If you run gradle with the -i option, you will see > a log message telling you that this is what is happening. > > There's things we could do to make this problem less likely to happen. We > could, for example, disable the short-circuit check if the task has had > actions added to it, and always execute the task. Our long term goal is to > replace the task actions, and so avoid problems like this entirely. As Adam said, Gradle could do a better job here in informing you about potential problems: 1.) Gradle could throw an exception (or at least issue a warning) if a Zip task is configured after the zip has been build. 2.) Our DSL kind of invites mistakes like the above. The distinction between a configuration closure and appending an action is very weak. As Adam said, we are thinking on something more expressive (and will deprecate the current mechanism at one point). - Hans -- Hans Dockter Founder, Gradle http://www.gradle.org, http://twitter.com/gradleorg CEO, Gradle Inc. - Gradle Training, Support, Consulting http://www.gradle.biz
