On 1 Mar 2014, at 5:53 am, Rob Platt <momentum...@gmail.com> 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
