Hi Luke, thank's for your response. For sure the target language and the build script language do not need to be the same. But the build language is an important factor in build tool choice.
The very first feature listed on the front page of Rake is that it uses standard Ruby. Amusingly, the originator of Rake was himself dubious about the benefits of another build system, given the effort involved in creating it (see http://rake.rubyforge.org/files/doc/rational_rdoc.html). This is a similar situation, and I do understand your point. However, we already have the build technology. Java 8 is an opportunity to open up the JVM to multiple languages even further than Java 7. Java should not, however, try to force people to use a polyglot approach. A project requiring java and javascript together will have to have a third wheel for its build system, choosing +XML or +groovy. In the worse case, someone decides to reinvent the wheel altogether and create a new build tool. This isn't far-fetched. After all, clojure has Leiningen, scala has sbt, and groovy has gradle ;-) In short, the build system should be polyglot, rather than shifting responsibility to the developer. Well, those are my 2 cents. But, there is no point in going forward unless there is enthusiasm for it. I do see the value of starting with support for building Nashorn based apps. As you say this is a separate matter. And it is an easy one I think. Nashorn is not compiled to bytecode. We only need plugins to support jjs and jrunscript. Unless you have something else in mind? Kind Regards Rob On Wed, Feb 26, 2014 at 4:34 PM, 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. > > > 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? :-) >> > >
