On 27 Feb 2014, at 6:04 am, Rob Platt <momentum...@gmail.com> wrote:
> 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? I would add some general purpose java script stuff:: - Unit and functional testing - Dependency management - General capability to run/start/stop applications, plus: - Some integration with nashorn, - Some web app specific integrations - Integrate this into the jvm and native domains as well. - Some convention plugins to wire everything together for various conventions. And heaps more. There’s plenty of interesting stuff to keep someone busy for quite a while, plus its very very useful stuff, if you’re interested in helping with this. > > 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? :-) > > -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
