On 28 Feb 2014, at 3:17 am, Rob Platt <momentum...@gmail.com> 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
