Thanks for the pointer Eric. On 22/05/2012, at 12:00 AM, Eric Berry <[email protected]> wrote:
> Hi Luke, > This does provide some conventional wiring, but I thought I'd throw this > out there anyway. > http://tellurianring.com/wiki/gradle/jslib > > I created this plugin a while back. It needs updating to work with the rc's, > but there were folks using it. > > Eric > > On Mon, May 21, 2012 at 3: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 > > > > > > -- > Learn from the past. Live in the present. Plan for the future. > Blog: http://eric-berry.blogspot.com > jEdit <http://www.jedit.org> - Programmer's Text Editor > Bazaar <http://bazaar.canonical.com> - Version Control for Humans
