On 27 Feb 2014, at 3:34 am, Luke Daley <luke.da...@gradleware.com> wrote:
> 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. I tend to agree. However, I’d be willing to experiment with a JS based build script DSL. Adding such a DSL would force some nice structural improvements to our DSL internals. > > > 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? :-) > -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
