On 4 Mar 2014, at 5:59 am, Rob Platt <momentum...@gmail.com> wrote:

> I've started this as a new topic, instead of continuing "javascript (nashorn) 
> build script engine for gradle", given that the scope has changed 
> significantly from the original post.
> 
> I have set up an experimental plugin for the generalized javascript support 
> at https://github.com/momentumjs/gradle-jsengine-plugin. We can 
> relocate/rename stuff as desired once its a bit more stable, but please feel 
> free to comment, review, raise issues or PR if you're interested.

Looks good to me.

The only feedback I’d give at this stage is that possibly 
DefaultJsEngineRegistry should search for a compatible engine in the order that 
they are added to the registry, and instead do the ordering in 
EmbeddedJsEnginePlugin for the embedded engines only. This way, the user can 
tweak the search order in the registry.

> 
> So far there's not much. I've put together a proof of concept for javascript 
> engine discovery. This is the equivalent of the native toolchain 
> functionality for javascript.
> 
> The default behavior is that available engines are ordered by ECMAScript 
> standards version, then by engine version. So a script which specifies that 
> it needs Rhino will use the latest Rhino. A script which can use any engine 
> would choose Nashorn over Rhino on the basis that it is ECMAScript 5.1 
> instead of 5 (if Nashorn is available). This seems the most natural ordering, 
> given that engines don't have an objective 'awesomeness' score. But of course 
> it could this could be modified by plugins. Engines might also be filtered 
> according to if a task needs specific features e.g. the ability to compile to 
> bytecode on disk, but I haven't gotten to this yet.
> 
> Next I'm going to look at the concept of javascript applications. These will 
> have engine requirements, equivalent to the "engines" section of a 
> package.json file. Indeed, I have it in mind that we should be able to 
> determine the appropriate engine to use from package.json files in future.

Sounds good. This is exactly the idea.

> 
> I'll report back when there is a basic "run" task. Then the plugin will 
> actually do something ;-)

Great.


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



Reply via email to