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/browserand
> 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
