State of javascript stuff in master.

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

State of javascript stuff in master.

Luke Daley-2
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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: State of javascript stuff in master.

Eric Berry
Hi Luke,
    This does provide some conventional wiring, but I thought I'd throw this out there anyway.

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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: State of javascript stuff in master.

Ken Sipe
In reply to this post by Luke Daley-2
Did you wire the output of coffeescript to input of war?

Sent from my iPhone

On May 21, 2012, at 5:40 PM, Luke Daley <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: State of javascript stuff in master.

Luke Daley-3




On 22/05/2012, at 12:07 AM, Ken Sipe <[hidden email]> 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 <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: State of javascript stuff in master.

Luke Daley-3
In reply to this post by Eric Berry
Thanks for the pointer Eric.

On 22/05/2012, at 12:00 AM, Eric Berry <[hidden email]> wrote:

Hi Luke,
    This does provide some conventional wiring, but I thought I'd throw this out there anyway.

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 <[hidden email]> 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
Loading...