On Tue, Apr 6, 2010 at 1:33 PM, Spencer Allain <[email protected]>wrote:
> 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.
>
This will definitely make it to the user's guide of the final 0.9 release.
>
> 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.
It is based on configuration time information which is always evaluated.
This is actually at the heart of it, e.g. a task should be reexecuted if the
configuration information has changed since the last run. If a task is up to
date, the actions of the task are simply not executed.
> 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.
>
Gradle provides the following:
task myTask {
outputs.upToDateWhen {
}
}
That way you can add custom logic on top of the automatic up to date
checking of Gradle.
onlyIf serves a different use case. You might want to skip a task if it is
after 4p.m. or something like that independent on whether it is up to date
or not.
- Hans
--
Hans Dockter
Founder, Gradle
http://www.gradle.org, http://twitter.com/gradleorg
CEO, Gradle Inc. - Gradle Training, Support, Consulting
http://www.gradle.biz
>
> 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
>
>
>
>
