On 17/06/10 2:21 AM, Rene Groeschke wrote:
Hi there,
I'm trying dig a bit deeper into the incremental build feature to speed up
our builds and learn something new :-)
Maybe I found a bug. Take a look at the following task:
task incrementalTest(type:Copy) {
def timestamp = new SimpleDateFormat('dd-MMM-yyyy - hh:mm').format(new
Date())
inputs.property('timestamp', timestamp)
from('samplein')
into('sampleout')
}
shouldn't this task marked as "not up to date" every minute? Gradle tolds
me every time that this task is upToDate (except the first call of course
where the copy action is performed the first time).
after adding an empty doLast closure, the incremental feature works as
expected:
task incrementalTest(type:Copy) {
def timestamp = new SimpleDateFormat('dd-MMM-yyyy - hh:mm').format(new
Date())
inputs.property('timestamp', timestamp)
from('samplein')
into('sampleout')
doLast{
}
}
is this expected behaviour?
No. I think you're running into http://jira.codehaus.org/browse/GRADLE-872
The basic problem is that the Copy task does it's own up-to-date
checking, which pre-dates the general purpose stuff, and as yet the two
systems aren't well integrated. So, in your case, the general purpose
stuff will decide that the task is out of date because the timestamp
property has changed, but the Copy specific stuff will ignore that and
decide that the files are actually up to date. Obviously, this will get
fixed soon.
A work around is to add a doFirst { } which deletes the output
directory. This will only be triggered if the task is out of date, and
will effectively short-circuit the Copy specific checks (at the cost of
potentially copying more stuff than is required).
--
Adam Murdoch
Gradle Developer
http://www.gradle.org
CTO, Gradle Inc. - Gradle Training, Support, Consulting
http://www.gradle.biz
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
