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 <adam.murd...@gradleware.com> wrote: > > On 26 Feb 2014, at 11:46 pm, Rob Platt <momentum...@gmail.com> wrote: > > Hello, > > Ambitiously, I proposed a js build script engine for gradle here:g > > > http://forums.gradle.org/gradle/topics/lets_make_a_javascript_nashorn_build_script_engine_for_gradle > > 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 > > > >
