This would be a tremendous amount of work for dubious (IMO) gain.
Most of your use cases don't really require the build script to be written in JS. I think it would be more useful to focus on supporting building Nashorn based applications than using Nashorn to evaluate build scripts. These are really two very separate pieces. On Wed, Feb 26, 2014 at 4:46 AM, Rob Platt <momentum...@gmail.com> wrote: > Hello, > Ambitiously, I proposed a js build script engine for gradle here: > 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? :-)