On 22/05/2012, at 12:07 AM, Ken Sipe <[email protected]> wrote:
> Did you wire the output of coffeescript to input of war?
Intentionally, no. You'd have to add that one line yourself for the time being.
In the short term we are staying away from opinionated conventions.
> Sent from my iPhone
>
> On May 21, 2012, at 5:40 PM, Luke Daley <[email protected]> wrote:
>
>> The two day spike is over, here's what we got.
>>
>> There are 5 plugins…
>>
>> * The “javascript-base” plugins adds a “javaScript” extension and provides
>> predefined repos for our JS repo
>> (http://repo.gradle.org/gradle/javascript-public/) and Google's.
>> * The “rhino” plugin adds support for using RhinoJS as a JavaScript runtime.
>> It configures a default rhino dependency, and provides a bunch of reusable
>> infrastructure for forking rhino based worker processes which is used by all
>> of the following plugins
>> * The “coffeescript-base” plugin adds support for compiling CoffeeScript
>> source into JavaScript (via a Rhino worker process). It also provides a
>> default coffeescript.js dependency (from our JS repo)
>> * The “jshint” plugin provides static analysis of JavaScript code (via a
>> Rhino worker process). It also provides a default jshint.js dependency (from
>> our JS repo)
>> * The “envjs” plugin provides a completely headless scriptable DOM runtime
>> (i.e. a simulated browser) (via a Rhino worker process). It also provides a
>> default envjs.js dependency (from our JS repo).
>>
>> I intentionally steered clear of providing any conventional wiring regarding
>> project structure (i.e. no source sets or predefined tasks). For example, if
>> you want to compile some coffee script you need to wire this together
>> yourself right now, but it's pretty straightforward.
>>
>> apply plugin: "coffeescript-base"
>>
>> repositories {
>> mavenCentral()
>> add javaScript.gradlePublicJsRepository
>> }
>>
>> task compileCoffeeScript(type: CoffeeScriptCompile) {
>> source fileTree("src/main/coffeescript")
>> destinationDir file("build/compiled/js")
>> }
>>
>> == Some interesting things ==
>>
>> The rhino plugin will be the base for all JavaScript based tooling. Because
>> I needed to use it as the basis for the other plugins, I put in some work
>> abstracting over our WorkerProcess stuff to make it very easy to write a
>> “RhinoWorker”. There might be some more generally reusable stuff for this
>> for “blocking” workers (i.e. they receive a payload and return a result).
>> This stuff is in
>> https://github.com/gradle/gradle/tree/master/subprojects/javascript/src/main/groovy/org/gradle/plugins/javascript/rhino/worker
>>
>> I ended up writing some HttpFileServer infrastructure for the envjs plugin.
>> I read a lot of stuff saying that JavaScript unit testing is most reliable
>> when you are accessing content over a HTTP server. This might be generally
>> useful outside of the JavaScript context. This is in
>> https://github.com/gradle/gradle/tree/master/subprojects/javascript/src/main/groovy/org/gradle/plugins/javascript/envjs/http
>>
>> We'll want to support different scriptable DOM runtimes (e.g. different real
>> browsers, or other simulated browsers) because some people won't be
>> satisfied with envjs (though it's the simplest and most portable). To this
>> end, I shook out some abstractions that would make this kind of thing
>> pluggable. See
>> https://github.com/gradle/gradle/tree/master/subprojects/javascript/src/main/groovy/org/gradle/plugins/javascript/envjs/browser
>> and impl here
>> https://github.com/gradle/gradle/tree/master/subprojects/javascript/src/main/groovy/org/gradle/plugins/javascript/envjs/internal
>>
>> There's no direct support for any test frameworks yet. However, the envjs
>> stuff is for that. With what's there now, it would be very easy to have
>> automated javascript tests in a Gradle build.
>>
>> All in all I'm pretty happy with it. There's certainly potential there.
>> Adding support for more tools written in JavaScript will be easy because of
>> the Rhino infrastructure. The DOM runtime stuff is very interesting too.
>> Users should be able to build support for specific test frameworks on top of
>> this if needed.
>>
>> I don't plan to do anymore, unless I uncover bugs while putting examples and
>> materials together.
>>
>> --
>> Luke Daley
>> Principal Engineer, Gradleware
>> http://gradleware.com
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>> http://xircles.codehaus.org/manage_email
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
