javascript (nashorn) build script engine for gradle

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

javascript (nashorn) build script engine for gradle

Rob Platt
Hello,

Ambitiously, I proposed a js build script engine for gradle here:


Given this is a complex task, I figured it might be best to discuss details on this mailing list.

I've seen a previous proposal about adding a build script engine for a different language (http://forums.gradle.org/gradle/topics/new_script_engine_for_gradle). I don't know if that went anywhere, but the proposals are quite similar. The main difference is that I'm not concerned about dependencies on groovy runtime jars. The focus is on the developer's experience. However, I consider the wrapper part of that experience (because its committed with projects). So, I would aim to make scripts in the wrapper Nashorn-based, using shell extensions as appropriate. "Turtles all the way down" as it were.

Typical use cases:
 * pure-javascript JVM projects which need to run up embedded servlet containers and databases
 * managing jar dependencies in javascript JVM projects
 * managing large or complex projects that have both java and javascript developers - different teams and languages, one build system

Typical stories:
As a gradle user I can:
 * start or clone projects with a nashorn-enabled gradle wrapper
 * run the wrapper as a jjs shell script using on unix
 * run the wrapper on windows with jjs, even without the .bat file
 * include gradle build scripts in javascript
 * include gradle build scripts in coffeescript
 * mix groovy and js/coffeescript build scripts in the same project
 * use gradle plugins from non-groovy build scripts
As a gradle plugin developer I can:
 * provide DSLs for additional JSR-223 scripting languages, reusing the Nashorn-enabled wrapper

I'm happy to make pull requests for changes needed to gradle/gradle to make this happen. What's the next step? :-)
Reply | Threaded
Open this post in threaded view
|

Re: javascript (nashorn) build script engine for gradle

Luke Daley-2
This would be a tremendous amount of work for dubious (IMO) gain.

Most of your use cases don't really require the build script to be written in JS. I think it would be more useful to focus on supporting building Nashorn based applications than using Nashorn to evaluate build scripts. These are really two very separate pieces.


On Wed, Feb 26, 2014 at 4:46 AM, Rob Platt <[hidden email]> wrote:

Hello,

Ambitiously, I proposed a js build script engine for gradle here:


Given this is a complex task, I figured it might be best to discuss details on this mailing list.

I've seen a previous proposal about adding a build script engine for a different language (http://forums.gradle.org/gradle/topics/new_script_engine_for_gradle). I don't know if that went anywhere, but the proposals are quite similar. The main difference is that I'm not concerned about dependencies on groovy runtime jars. The focus is on the developer's experience. However, I consider the wrapper part of that experience (because its committed with projects). So, I would aim to make scripts in the wrapper Nashorn-based, using shell extensions as appropriate. "Turtles all the way down" as it were.

Typical use cases:
 * pure-javascript JVM projects which need to run up embedded servlet containers and databases
 * managing jar dependencies in javascript JVM projects
 * managing large or complex projects that have both java and javascript developers - different teams and languages, one build system

Typical stories:
As a gradle user I can:
 * start or clone projects with a nashorn-enabled gradle wrapper
 * run the wrapper as a jjs shell script using on unix
 * run the wrapper on windows with jjs, even without the .bat file
 * include gradle build scripts in javascript
 * include gradle build scripts in coffeescript
 * mix groovy and js/coffeescript build scripts in the same project
 * use gradle plugins from non-groovy build scripts
As a gradle plugin developer I can:
 * provide DSLs for additional JSR-223 scripting languages, reusing the Nashorn-enabled wrapper

I'm happy to make pull requests for changes needed to gradle/gradle to make this happen. What's the next step? :-)

Reply | Threaded
Open this post in threaded view
|

Re: javascript (nashorn) build script engine for gradle

Rob Platt
Hi Luke, thank's for your response.

For sure the target language and the build script language do not need to be the same. But the build language is an important factor in build tool choice.

The very first feature listed on the front page of Rake is that it uses standard Ruby. Amusingly, the originator of Rake was himself dubious about the benefits of another build system, given the effort involved in creating it (see http://rake.rubyforge.org/files/doc/rational_rdoc.html). This is a similar situation, and I do understand your point. However, we already have the build technology.

Java 8 is an opportunity to open up the JVM to multiple languages even further than Java 7. Java should not, however, try to force people to use a polyglot approach. A project requiring java and javascript together will have to have a third wheel for its build system, choosing +XML or +groovy. In the worse case, someone decides to reinvent the wheel altogether and create a new build tool. This isn't far-fetched. After all, clojure has Leiningen, scala has sbt, and groovy has gradle ;-)

In short, the build system should be polyglot, rather than shifting responsibility to the developer.

Well, those are my 2 cents. But, there is no point in going forward unless there is enthusiasm for it.

I do see the value of starting with support for building Nashorn based apps. As you say this is a separate matter. And it is an easy one I think. Nashorn is not compiled to bytecode. We only need plugins to support jjs and jrunscript. Unless you have something else in mind?

Kind Regards
Rob


On Wed, Feb 26, 2014 at 4:34 PM, Luke Daley <[hidden email]> wrote:
This would be a tremendous amount of work for dubious (IMO) gain.

Most of your use cases don't really require the build script to be written in JS. I think it would be more useful to focus on supporting building Nashorn based applications than using Nashorn to evaluate build scripts. These are really two very separate pieces.


On Wed, Feb 26, 2014 at 4:46 AM, Rob Platt <[hidden email]> wrote:

Hello,

Ambitiously, I proposed a js build script engine for gradle here:


Given this is a complex task, I figured it might be best to discuss details on this mailing list.

I've seen a previous proposal about adding a build script engine for a different language (http://forums.gradle.org/gradle/topics/new_script_engine_for_gradle). I don't know if that went anywhere, but the proposals are quite similar. The main difference is that I'm not concerned about dependencies on groovy runtime jars. The focus is on the developer's experience. However, I consider the wrapper part of that experience (because its committed with projects). So, I would aim to make scripts in the wrapper Nashorn-based, using shell extensions as appropriate. "Turtles all the way down" as it were.

Typical use cases:
 * pure-javascript JVM projects which need to run up embedded servlet containers and databases
 * managing jar dependencies in javascript JVM projects
 * managing large or complex projects that have both java and javascript developers - different teams and languages, one build system

Typical stories:
As a gradle user I can:
 * start or clone projects with a nashorn-enabled gradle wrapper
 * run the wrapper as a jjs shell script using on unix
 * run the wrapper on windows with jjs, even without the .bat file
 * include gradle build scripts in javascript
 * include gradle build scripts in coffeescript
 * mix groovy and js/coffeescript build scripts in the same project
 * use gradle plugins from non-groovy build scripts
As a gradle plugin developer I can:
 * provide DSLs for additional JSR-223 scripting languages, reusing the Nashorn-enabled wrapper

I'm happy to make pull requests for changes needed to gradle/gradle to make this happen. What's the next step? :-)


Reply | Threaded
Open this post in threaded view
|

Re: javascript (nashorn) build script engine for gradle

Adam Murdoch
In reply to this post by Luke Daley-2

On 27 Feb 2014, at 3:34 am, Luke Daley <[hidden email]> wrote:

This would be a tremendous amount of work for dubious (IMO) gain.

Most of your use cases don't really require the build script to be written in JS. I think it would be more useful to focus on supporting building Nashorn based applications than using Nashorn to evaluate build scripts. These are really two very separate pieces.

I tend to agree. However, I’d be willing to experiment with a JS based build script DSL. Adding such a DSL would force some nice structural improvements to our DSL internals.



On Wed, Feb 26, 2014 at 4:46 AM, Rob Platt <[hidden email]> wrote:

Hello,

Ambitiously, I proposed a js build script engine for gradle here:


Given this is a complex task, I figured it might be best to discuss details on this mailing list.

I've seen a previous proposal about adding a build script engine for a different language (http://forums.gradle.org/gradle/topics/new_script_engine_for_gradle). I don't know if that went anywhere, but the proposals are quite similar. The main difference is that I'm not concerned about dependencies on groovy runtime jars. The focus is on the developer's experience. However, I consider the wrapper part of that experience (because its committed with projects). So, I would aim to make scripts in the wrapper Nashorn-based, using shell extensions as appropriate. "Turtles all the way down" as it were.

Typical use cases:
 * pure-javascript JVM projects which need to run up embedded servlet containers and databases
 * managing jar dependencies in javascript JVM projects
 * managing large or complex projects that have both java and javascript developers - different teams and languages, one build system

Typical stories:
As a gradle user I can:
 * start or clone projects with a nashorn-enabled gradle wrapper
 * run the wrapper as a jjs shell script using on unix
 * run the wrapper on windows with jjs, even without the .bat file
 * include gradle build scripts in javascript
 * include gradle build scripts in coffeescript
 * mix groovy and js/coffeescript build scripts in the same project
 * use gradle plugins from non-groovy build scripts
As a gradle plugin developer I can:
 * provide DSLs for additional JSR-223 scripting languages, reusing the Nashorn-enabled wrapper

I'm happy to make pull requests for changes needed to gradle/gradle to make this happen. What's the next step? :-)



--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com



Reply | Threaded
Open this post in threaded view
|

Re: javascript (nashorn) build script engine for gradle

Adam Murdoch
In reply to this post by Rob Platt

On 27 Feb 2014, at 6:04 am, Rob Platt <[hidden email]> wrote:

Hi Luke, thank's for your response.

For sure the target language and the build script language do not need to be the same. But the build language is an important factor in build tool choice.

The very first feature listed on the front page of Rake is that it uses standard Ruby. Amusingly, the originator of Rake was himself dubious about the benefits of another build system, given the effort involved in creating it (see http://rake.rubyforge.org/files/doc/rational_rdoc.html). This is a similar situation, and I do understand your point. However, we already have the build technology.

Java 8 is an opportunity to open up the JVM to multiple languages even further than Java 7. Java should not, however, try to force people to use a polyglot approach. A project requiring java and javascript together will have to have a third wheel for its build system, choosing +XML or +groovy. In the worse case, someone decides to reinvent the wheel altogether and create a new build tool. This isn't far-fetched. After all, clojure has Leiningen, scala has sbt, and groovy has gradle ;-)

In short, the build system should be polyglot, rather than shifting responsibility to the developer.

Well, those are my 2 cents. But, there is no point in going forward unless there is enthusiasm for it.

I do see the value of starting with support for building Nashorn based apps. As you say this is a separate matter. And it is an easy one I think. Nashorn is not compiled to bytecode. We only need plugins to support jjs and jrunscript. Unless you have something else in mind?

I would add some general purpose java script stuff::

- Unit and functional testing
- Dependency management
- General capability to run/start/stop applications, plus:
- Some integration with nashorn,
- Some web app specific integrations
- Integrate this into the jvm and native domains as well.
- Some convention plugins to wire everything together for various conventions.

And heaps more. There’s plenty of interesting stuff to keep someone busy for quite a while, plus its very very useful stuff, if you’re interested in helping with this.



Kind Regards
Rob


On Wed, Feb 26, 2014 at 4:34 PM, Luke Daley <[hidden email]> wrote:
This would be a tremendous amount of work for dubious (IMO) gain.

Most of your use cases don't really require the build script to be written in JS. I think it would be more useful to focus on supporting building Nashorn based applications than using Nashorn to evaluate build scripts. These are really two very separate pieces.


On Wed, Feb 26, 2014 at 4:46 AM, Rob Platt <[hidden email]> wrote:

Hello,

Ambitiously, I proposed a js build script engine for gradle here:


Given this is a complex task, I figured it might be best to discuss details on this mailing list.

I've seen a previous proposal about adding a build script engine for a different language (http://forums.gradle.org/gradle/topics/new_script_engine_for_gradle). I don't know if that went anywhere, but the proposals are quite similar. The main difference is that I'm not concerned about dependencies on groovy runtime jars. The focus is on the developer's experience. However, I consider the wrapper part of that experience (because its committed with projects). So, I would aim to make scripts in the wrapper Nashorn-based, using shell extensions as appropriate. "Turtles all the way down" as it were.

Typical use cases:
 * pure-javascript JVM projects which need to run up embedded servlet containers and databases
 * managing jar dependencies in javascript JVM projects
 * managing large or complex projects that have both java and javascript developers - different teams and languages, one build system

Typical stories:
As a gradle user I can:
 * start or clone projects with a nashorn-enabled gradle wrapper
 * run the wrapper as a jjs shell script using on unix
 * run the wrapper on windows with jjs, even without the .bat file
 * include gradle build scripts in javascript
 * include gradle build scripts in coffeescript
 * mix groovy and js/coffeescript build scripts in the same project
 * use gradle plugins from non-groovy build scripts
As a gradle plugin developer I can:
 * provide DSLs for additional JSR-223 scripting languages, reusing the Nashorn-enabled wrapper

I'm happy to make pull requests for changes needed to gradle/gradle to make this happen. What's the next step? :-)




--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com



Reply | Threaded
Open this post in threaded view
|

Re: javascript (nashorn) build script engine for gradle

Adam Murdoch
In reply to this post by Rob Platt

On 26 Feb 2014, at 11:46 pm, Rob Platt <[hidden email]> wrote:

Hello,

Ambitiously, I proposed a js build script engine for gradle here:


Given this is a complex task, I figured it might be best to discuss details on this mailing list.

I've seen a previous proposal about adding a build script engine for a different language (http://forums.gradle.org/gradle/topics/new_script_engine_for_gradle). I don't know if that went anywhere, but the proposals are quite similar. The main difference is that I'm not concerned about dependencies on groovy runtime jars. The focus is on the developer's experience. However, I consider the wrapper part of that experience (because its committed with projects). So, I would aim to make scripts in the wrapper Nashorn-based, using shell extensions as appropriate. "Turtles all the way down" as it were.

Typical use cases:
 * pure-javascript JVM projects which need to run up embedded servlet containers and databases
 * managing jar dependencies in javascript JVM projects
 * managing large or complex projects that have both java and javascript developers - different teams and languages, one build system

Typical stories:
As a gradle user I can:
 * start or clone projects with a nashorn-enabled gradle wrapper
 * run the wrapper as a jjs shell script using on unix
 * run the wrapper on windows with jjs, even without the .bat file
 * include gradle build scripts in javascript
 * include gradle build scripts in coffeescript
 * mix groovy and js/coffeescript build scripts in the same project
 * use gradle plugins from non-groovy build scripts
As a gradle plugin developer I can:
 * provide DSLs for additional JSR-223 scripting languages, reusing the Nashorn-enabled wrapper

I'm happy to make pull requests for changes needed to gradle/gradle to make this happen. What's the next step? :-)

The next step would be for you to put together a specification of what you’d like to do, and we can go from there.

Just be aware that at this stage, I would only be interested in providing some way to author build scripts in JavaScript. The other stuff I would consider provisional based on whether this turns out to be a practical approach or not.


--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com



Reply | Threaded
Open this post in threaded view
|

javascript (nashorn) build script engine for gradle

Rob Platt
Hi Adam, thanks for the feedback.

Definitely interested in the general purpose stuff. It seems very sensible to focus my on nashorn support and tooling for now. This will be useful experience for me as a contributor and we can always revisit the build engine ideas later.

How do want to proceed -- I'm happy for the roadmap to be driven by you guys, as you have overall vision of gradle. Or did you want me to drive the specification process.

A good starting point would be to consider how we want to organize javascript execution, since this will be the basis of everything else.  The most complete approach would give existing gradle plugins the option of nashorn in place of rhino, where it is available. A good example would be the coffee script compiler built into gradle. This must be done without imposing Java 1.6+ on Gradle of course. This is fairly straight forward with shell exec, but it would be advantageous to be able to use nashorn without shell exec, i.e. JSR-223 scripting API, for flexibility of passing information between gradle and integrated js scripts. Unfortunately this is Java 1.6+, so we'd be looking at stubbing out to keep Java 1.5 quiet... The other gotcha is testing on different JDKs.

Alternatively, the nashorn support can be completely and utterly separate from core gradle. This is simpler, but I don't see a way for existing plugins to benefit...?

Cheers
Rob

On Wednesday, February 26, 2014, Adam Murdoch <[hidden email]> wrote:

On 26 Feb 2014, at 11:46 pm, Rob Platt <[hidden email]> wrote:

Hello,

Ambitiously, I proposed a js build script engine for gradle here:g


Given this is a complex task, I figured it might be best to discuss details on this mailing list.

I've seen a previous proposal about adding a build script engine for a different language (http://forums.gradle.org/gradle/topics/new_script_engine_for_gradle). I don't know if that went anywhere, but the proposals are quite similar. The main difference is that I'm not concerned about dependencies on groovy runtime jars. The focus is on the developer's experience. However, I consider the wrapper part of that experience (because its committed with projects). So, I would aim to make scripts in the wrapper Nashorn-based, using shell extensions as appropriate. "Turtles all the way down" as it were.

Typical use cases:
 * pure-javascript JVM projects which need to run up embedded servlet containers and databases
 * managing jar dependencies in javascript JVM projects
 * managing large or complex projects that have both java and javascript developers - different teams and languages, one build system

Typical stories:
As a gradle user I can:
 * start or clone projects with a nashorn-enabled gradle wrapper
 * run the wrapper as a jjs shell script using on unix
 * run the wrapper on windows with jjs, even without the .bat file
 * include gradle build scripts in javascript
 * include gradle build scripts in coffeescript
 * mix groovy and js/coffeescript build scripts in the same project
 * use gradle plugins from non-groovy build scripts
As a gradle plugin developer I can:
 * provide DSLs for additional JSR-223 scripting languages, reusing the Nashorn-enabled wrapper

I'm happy to make pull requests for changes needed to gradle/gradle to make this happen. What's the next step? :-)

The next step would be for you to put together a specification of what you’d like to do, and we can go from there.

Just be aware that at this stage, I would only be interested in providing some way to author build scripts in JavaScript. The other stuff I would consider provisional based on whether this turns out to be a practical approach or not.


--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com



Reply | Threaded
Open this post in threaded view
|

Re: javascript (nashorn) build script engine for gradle

Adam Murdoch

On 28 Feb 2014, at 3:17 am, Rob Platt <[hidden email]> wrote:

Hi Adam, thanks for the feedback.

Definitely interested in the general purpose stuff. It seems very sensible to focus my on nashorn support and tooling for now. This will be useful experience for me as a contributor and we can always revisit the build engine ideas later.

That would be awesome.


How do want to proceed -- I'm happy for the roadmap to be driven by you guys, as you have overall vision of gradle. Or did you want me to drive the specification process.

A good starting point would be to consider how we want to organize javascript execution, since this will be the basis of everything else.  The most complete approach would give existing gradle plugins the option of nashorn in place of rhino, where it is available. A good example would be the coffee script compiler built into gradle. This must be done without imposing Java 1.6+ on Gradle of course. This is fairly straight forward with shell exec, but it would be advantageous to be able to use nashorn without shell exec, i.e. JSR-223 scripting API, for flexibility of passing information between gradle and integrated js scripts. Unfortunately this is Java 1.6+, so we'd be looking at stubbing out to keep Java 1.5 quiet... The other gotcha is testing on different JDKs.

We have some good infrastructure for testing on different platforms and jvms, so this is fine.

I’d also be completely fine with any javascript support only working with jdk 1.6+. This is already the case with our Scala support. I’d even be fine with requiring java 1.7+ for javascript support.

Stepping back, to tackle this problem I’d start with some modelling rather than with low level capabilities, something like:

1. Introduce the concept of a JavaScript application (similar to a native executable or jvm application). At this stage, this is just something to provide some structure.
- A JavaScript application has some source files that it is built from. At this stage, only JavaScript source files would be supported.
2. Add lifecycle tasks to run and install a JavaScript application
- At this stage, run would use the existing rhino infrastructure.
3. Introduce the concept of a JavaScript runtime and make this pluggable (similar to native toolchains).
- A ‘rhino’ plugin would provide the rhino support, and a ‘nashorn’ plugin would provide the nashorn support. These plugins would share a bunch of stuff. It would be similar to the ‘gcc’ and ‘clang’ tool chains.
- The run task would use the ‘best’ available runtime.
- Retro-fit the existing tasks to also sit on top of this infrastructure.

Then, we can go in a bunch of directions from there. Some ideas, in no particular order:

- Generalise the concept of a JavaScript application into a JavaScript component, and add a few more types of components. For example, we might add the concept of a JavaScript library or a web app or a node module.
- Introduce more JavaScript runtimes (eg node, browser) and implementations.
- Introduce unit testing and functional testing for JavaScript components.
- Introduce dependency management for JavaScript components, plus some integration with existing solutions in that domain.
- Add support for more input languages that can generate JavaScript output.
- For Web components, add support for other types of outputs - CSS, static resources, and so on.
- Introduce minification and other transformations for JavaScript output.
- Introduce static analysis for JavaScript source.
- Generalise the concept of an application and share this with the Jvm and native domains. This means, for example, you’d be able to install or create a distribution for any kind of command-line application, regardless of how it is implemented.

And the list keeps going ….


--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com



Reply | Threaded
Open this post in threaded view
|

Re: javascript (nashorn) build script engine for gradle

Rob Platt

Adam Murdoch wrote:

Stepping back, to tackle this problem I’d start with some modelling rather than with low level capabilities, something like:

1. Introduce the concept of a JavaScript application (similar to a native executable or jvm application). At this stage, this is just something to provide some structure.
- A JavaScript application has some source files that it is built from. At this stage, only JavaScript source files would be supported.
2. Add lifecycle tasks to run and install a JavaScript application
- At this stage, run would use the existing rhino infrastructure.
3. Introduce the concept of a JavaScript runtime and make this pluggable (similar to native toolchains).
- A ‘rhino’ plugin would provide the rhino support, and a ‘nashorn’ plugin would provide the nashorn support. These plugins would share a bunch of stuff. It would be similar to the ‘gcc’ and ‘clang’ tool chains.
- The run task would use the ‘best’ available runtime.
- Retro-fit the existing tasks to also sit on top of this infrastructure.



Sounds good! I'll have a think about this, and take a look at how the native toolchains are organized, over the weekend.

Maybe we can get Eric Wendelin or the others over at the gradle js community plugin interested too? That plugin is going very strong and don't want to spoil their fun ;-)

Regards
Rob
Reply | Threaded
Open this post in threaded view
|

Re: javascript (nashorn) build script engine for gradle

Adam Murdoch

On 1 Mar 2014, at 5:53 am, Rob Platt <[hidden email]> wrote:


Adam Murdoch wrote:

Stepping back, to tackle this problem I’d start with some modelling rather than with low level capabilities, something like:

1. Introduce the concept of a JavaScript application (similar to a native executable or jvm application). At this stage, this is just something to provide some structure.
- A JavaScript application has some source files that it is built from. At this stage, only JavaScript source files would be supported.
2. Add lifecycle tasks to run and install a JavaScript application
- At this stage, run would use the existing rhino infrastructure.
3. Introduce the concept of a JavaScript runtime and make this pluggable (similar to native toolchains).
- A ‘rhino’ plugin would provide the rhino support, and a ‘nashorn’ plugin would provide the nashorn support. These plugins would share a bunch of stuff. It would be similar to the ‘gcc’ and ‘clang’ tool chains.
- The run task would use the ‘best’ available runtime.
- Retro-fit the existing tasks to also sit on top of this infrastructure.



Sounds good! I'll have a think about this, and take a look at how the native toolchains are organized, over the weekend.

Great.

The key ideas, which may not be entirely clear from the native toolchains, are that:

1. A native component (actually a native binary) declares which platform it should run on. In the case of the native component this basically means which operating system and architecture.
2. There is a registry of native toolchains, each of which can build binaries for a certain set of platforms.
3. When Gradle tries to build a native binary, it runs down the list of registered toolchains and selects the first toolchain that is both available (ie installed or installable) and can build binaries for the target platform.
4. A build script or a plugin can configure the registry, and so can control exactly which tool chains are available.

In this way, Gradle basically discovers the native tools that can build the native binary.

I would like to use the same pattern for building things for the jvm too, at some point.

As far as JavaScript applications go, we’re more interested in spinning up a runtime to execute stuff (possibly build-time tools or tests or the application itself). However, I think the same pattern would be very useful:

1. A JavaScript component declares which JavaScript platform it should run on. Here, we’re talking JavaScript (+minimum version) and later some specialisations - node.js, browser, jvm.
2. There is a registry of JavaScript engines, each of which provides a certain set of JavaScript runtimes.
3. When Gradle needs to run a JavaScript component, it runs down the list of registered engines and selects the first one that is both available and provides the target runtime.
4. The registry is configurable to allow control over exactly which engines are available.



Maybe we can get Eric Wendelin or the others over at the gradle js community plugin interested too? That plugin is going very strong and don't want to spoil their fun ;-)

Very good idea.


--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com