For the record, I wasn't advocating using "clean" (see my entire
e-mail after the first sentence). I was just noting that this is the
textbook problem for which "clean" is presented as an answer.
It shouldn't be hard to hook up the compatibility you are looking for.
As you say, the one thing that would be nice is to know the names of
the source files the previous time the task was executed.
~~ Robert.
On Mon, Jun 25, 2012 at 8:24 PM, Luke Daley <luke.da...@gradle.biz> wrote:
>
>
>
>
> On 25/06/2012, at 3:31 PM, Howard Lewis Ship <hls...@gmail.com> wrote:
>
>
>
> On Mon, Jun 25, 2012 at 12:14 PM, Robert Fischer
> <robert.fisc...@smokejumperit.com> wrote:
>>
>> This is what "clean" is there for. It's a common problem caused by the
>> fact that the build system doesn't know what output files require
>> which other output files, or which input files produced which output
>> files. But, of course, we can always teach it what the rules are.
>>
>
> I'm not asking that build system to magically know; I'd assume that mapping
> would be trapped inside a bit of my code. I'm slightly off-put by the
> direction to use "clean"; as I understood it, part of the appeal of Gradle
> is never having to use "clean".
>
>
> Correct, no build should require "clean" for reproducibility.
>
>
>>
>> You could also add a filter in your input to exclude an input file if
>> the last modified time of the input file is less than the last
>> modified time of the output file.
>
>
> That's kind of where I'm headed, though for the meantime, I'm deleting the
> output directory early, and just re-building all .js from all .coffee.
>
>
>>
>>
>> If you know the mapping, you could always wipe out the bogus output
>> files first based in the input file names, although I don't know a
>> clever/declarative Gradle way of specifying that behavior. At least,
>> not off the top of my head...there might be some clever filtering
>> manipulation you could perform.
>
>
>
> I'm kind of picturing some additional method annotations for method to be
> invoked when a source file from a previous build no longer exists. That
> would be very handy, since my code could re-do the mapping from input file
> to output file and delete the output file.
>
>
>>
>>
>> If you want to add that code, though, you're hitting "plugin" levels
>> of complexity pretty quick here.
>
>
> My goal is to turn this into a plugin ... except that it looks like 1.1 will
> have (experimental) support for this out-of-the-box.
>
>>
>>
>> ~~ Robert.
>>
>>
>> On Mon, Jun 25, 2012 at 12:39 PM, Howard Lewis Ship <hls...@gmail.com>
>> wrote:
>> > I've been working on a little script to assist with compiling
>> > CoffeeScript
>> > for my project. I have it partially working, but am seeking some help on
>> > making it completely correct.
>> >
>> > Here's the main code:
>> >
>> > coffeescript.gradle:
>> > import ro.isdc.wro.model.resource.*
>> > import ro.isdc.wro.extensions.processor.js.*
>> >
>> > buildscript {
>> > repositories { mavenCentral() }
>> > dependencies {
>> > classpath "ro.isdc.wro4j:wro4j-extensions:${versions.wro4j}"
>> > }
>> > }
>> >
>> > class CompileCoffeeScript extends DefaultTask {
>> > def srcDir = "src/main/coffeescript"
>> >
>> > def outputDir = "${project.buildDir}/compiled-coffeescript"
>> >
>> > @InputDirectory
>> > File getSrcDir() { project.file(srcDir) }
>> >
>> > @OutputDirectory
>> > File getOutputDir() { project.file(outputDir) }
>> >
>> > @TaskAction
>> > void doCompile() {
>> > logger.info "Compiling CoffeeScript sources from $srcDir into
>> > $outputDir"
>> >
>> > def tree = project.fileTree srcDir, {
>> > include '**/*.coffee'
>> > }
>> >
>> > tree.visit { visit ->
>> > if (visit.directory) return
>> >
>> > def inputFile = visit.file
>> > def inputPath = visit.path
>> > def outputPath = inputPath.replaceAll(/\.coffee$/, '.js')
>> > def outputFile = new File(outputDir, outputPath)
>> >
>> > logger.info "Compiling ${inputPath}"
>> >
>> > outputFile.parentFile.mkdirs()
>> >
>> > def resource = Resource.create(inputFile.absolutePath,
>> > ResourceType.JS)
>> >
>> > new CoffeeScriptProcessor().process(resource,
>> > inputFile.newReader(),
>> > outputFile.newWriter())
>> > }
>> > }
>> >
>> > }
>> >
>> > project.ext.CompileCoffeeScript = CompileCoffeeScript
>> >
>> > And here's what I've added to my main build script:
>> >
>> > apply from: "coffeescript.gradle"
>> >
>> > task compileCoffeeScript(type: CompileCoffeeScript)
>> >
>> > processResources {
>> > from compileCoffeeScript
>> > }
>> >
>> >
>> > This works partially: when I change a source .coffee file, or add a new
>> > .coffee file, then all of the .coffee files are recompiled to JavaScript
>> > and
>> > included in the output JAR file (that is, task jar depends on task
>> > processResources which now depends on task compileCoffeeScript).
>> >
>> > However, if I delete an input file, I'm only getting partial behavior:
>> >
>> > :tapestry-core:compileCoffeeScript
>> > Executing task ':tapestry-core:compileCoffeeScript' due to:
>> > Input file
>> >
>> > /Users/hlship/workspaces/tapestry/tapestry5/tapestry-core/src/main/coffeescript/proto/bye.coffee
>> > for task ':tapestry-core:compileCoffeeScript' removed.
>> > Compiling CoffeeScript sources from src/main/coffeescript into
>> >
>> > /Users/hlship/workspaces/tapestry/tapestry5/tapestry-core/build/compiled-coffeescript
>> > Compiling proto/hello.coffee
>> > :tapestry-core:processResources
>> >
>> >
>> > ... but I see the output .js file for the deleted input .coffee file
>> > still
>> > in the JAR (and in build/compiled-coffeescript). In other words,
>> > deleting a
>> > source file does not cause the previously generated output file to be
>> > deleted.
>> >
>> > Secondly, and perhaps this is related, when I change ANY .coffee file,
>> > then
>> > ALL .coffee files are recompiled. CoffeeScript is unlike Java, each
>> > file is
>> > pretty much independent of all others (it's all going to be very late
>> > bound
>> > inside the client browser).
>> >
>> > So ... should I simply delete the output directory inside my doCompile()
>> > method? Given the message in the console output above, it seems like
>> > there
>> > could be a notification to a task that an input file was deleted and it
>> > should ensure the corresponding output file(s) are deleted.
>> >
>> > But if I want a more "incremental" style, am I expected to walk the
>> > output
>> > directory and delete anything that doesn't have a corresponding source
>> > file?
>> >
>> > And, is there a base class to extend from that handles more of this for
>> > me?
>> > SourceTask doesn't seem to do quite what I want.
>> >
>> > Thanks in advance for any guidance.
>> >
>> > $ gradle --version
>> >
>> > ------------------------------------------------------------
>> > Gradle 1.0
>> > ------------------------------------------------------------
>> >
>> > Gradle build time: Tuesday, June 12, 2012 12:56:21 AM UTC
>> > Groovy: 1.8.6
>> > Ant: Apache Ant(TM) version 1.8.2 compiled on December 20 2010
>> > Ivy: 2.2.0
>> > JVM: 1.7.0_04 (Oracle Corporation 23.0-b21)
>> > OS: Mac OS X 10.7.4 x86_64
>> >
>> >
>> > --
>> > Howard M. Lewis Ship
>> >
>> > Creator of Apache Tapestry
>> >
>> > The source for Tapestry training, mentoring and support. Contact me to
>> > learn
>> > how I can get you up and productive in Tapestry fast!
>> >
>> > (971) 678-5210
>> > http://howardlewisship.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>> http://xircles.codehaus.org/manage_email
>>
>>
>
>
>
> --
> Howard M. Lewis Ship
>
> Creator of Apache Tapestry
>
> The source for Tapestry training, mentoring and support. Contact me to learn
> how I can get you up and productive in Tapestry fast!
>
> (971) 678-5210
> http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
