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
