I've not dug into the sources to confirm this, but I suspect that all jar/war/tar/zip type tasks for a project are auto-added as dependencies of the assemble task (which is always run as part of the build task).
As for why myArchive believes that it's up-to-date, it's probably something subtle (like the final destination of the archive isn't where you think it went). I was going to point to an example of how UP-TO-DATE is tested within the latest user's guide, but realized there wasn't one, as it shows only how to explicitly skip/disable tasks. The sources and targets (inputs and outputs) used for each task type for up-to-date comparisons would be a good addition to the user's guide. An example or two would be very helpful to understand how gradle internally determines that a task doesn't need to be actually executed. I'm starting to wonder if it determines it based solely on configuration time information, and only the execution portion of the task is skipped if the up-to-date check fails. All examples in the user's guide of archive tasks specify the "from" in the configuration phase, but your "from" won't ever get assigned until the execution phase (which is being skipped). Now I'm curious myself as to how exactly UP-TO-DATE functions :-) I've used my own internal execution time tests to skip portions of the execution before onlyIf() and incremental compilation was part of gradle, so I really have never relied up on it. It almost seems that a "doJustBeforeNormalExecution" would be valuable to implement an UP-TO-DATE test, which could contain logic code to determine just before the rest of the execution as to whether or not the rest of execution should need to occur. I really am not sure if that's how it works or not. I do really suspect now that it uses configuration time information to make the decision though. Try putting your myArchive "from" inside of a configure closure and see if it behaves differently. -Spencer --- On Tue, 4/6/10, Geronimo M. H. <[email protected]> wrote: From: Geronimo M. H. <[email protected]> Subject: [gradle-user] Hm - strange To: [email protected] Date: Tuesday, April 6, 2010, 6:38 AM Hello, on experimenting with archive tasks, I got surprised by the way, things work. An excerpt from my build-file is this: task tellSources << { def sources = files(subprojects.collect { project-> [ project.sourceSets.main.allJava ] }) // sources.each { println it } copy { from sources into file(rootProject.buildDir).absolutePath + '/src' } } task myArchive(type: Tar) << { baseName = 'rednose' destinationDir = rootProject.buildDir from(file(rootProject.buildDir).absolutePath + '/src') { include '**/*.java' } } myArchive.dependsOn tellSources My defaultTasks are 'clean' and 'build' - so when I run gradle without any argument, I was very surprised, that the build-dir contained a src-directory which all sources in. >From my point of view, none of my bizarre task-definition is part of the standard task-graph (or at least should not be). When I look at the executed tasks, I'll find this: ...$ fgradle :clean UP-TO-DATE :SRLibAppBase:clean :SRLibDA:clean :SRLibGui:clean :SRServiceManager:clean :SRSrvSample:clean :SRStarter:clean :compileJava UP-TO-DATE :processResources UP-TO-DATE :classes UP-TO-DATE :jar :tellSources :myArchive UP-TO-DATE :assemble :compileTestJava UP-TO-DATE :processTestResources UP-TO-DATE :testClasses UP-TO-DATE :uploadArchives :test UP-TO-DATE :check UP-TO-DATE :build ... So how did my creepy task definitions find their way into the 'build'-task-graph? And even more strange: when I execute "gradle myArchive", I get the message, that "myArchive is UP-TO-DATE, but no archive has been created. Can anybody shine me a light on what's happening? kind regards Geronimo --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
