On 17/05/2012, at 6:12 AM, Luke Daley wrote: > Howdy, > > Here are some disjointed thoughts about JavaScript support, as provided by > the different 3rd party plugins. > > The biggest problem I can see is that none of these plugins play well > together, which to some extent is a symptom of there being many different > ways to “do JavaScript”. Also, I think it's a symptom of there being no core > modelling in this area. > > I've been contemplating what a “javascript-base” plugin might provide if we > were to do such a thing. > > Providing something like sourceSets would probably be a good start. At the > moment most tasks are using references to directories and finding all js > files manually, which is unnecessary and defeats task chaining through > buildable inputs. I'm not sure what else a JavaScript source set would do > besides be a glorified FileTree. I'm not sure at this point what else there > is to model, or is worth modelling.
A couple more things a SourceSet would provide: * A way to declare the purpose of some javascript source files: is it part of the web app, or is it a test script, or is it a test fixture, or is it a tool, or … * A way to declare the dependencies of some javascript source. In general, a set of javascript source has dependencies on other javascript libraries, and on various other kinds of artefacts, such as css or images. A few other things we should model: * The concept of a javascript library. * Dependency management for javascript libraries. This, most importantly, would involve defining a convention for publishing a javascript component, and automating the work that has to happen to follow this convention. * The connection between javascript and web applications. Javascript almost always ends up in a web application. Our model should reflect this fact, our infrastructure should automate the bundling, there should be conventions for how this happens, and our IDE integration should expose this concept. There is also some goodness we can reuse from the c++ dependency management stuff we want to do: * The idea of variants: a minified variant of a script vs a non-minified variant of a script. * The idea of packaging: a library distributed as a script vs a library distributed in a zip with supporting resources, dependencies and so on. * The idea of bundling: a published library may include some or all of the dependencies of that library. > > Not sure what we would do code wise to achieve this, but promotion of using > SourceTask as a super class would probably do wonders in this space. > > Providing some JavaScript runtime support would be useful too. At the very > least, this would be support for RhinoJS. It could eventually expand to > include PhantomJS and possibly real browsers automated with WebDriver too. A > lot of the javascript tools (compressors, static analysis etc.) are written > in JavaScript, hence the need for a runtime. > > As for testing, I'm still not sure what to do. The different test frameworks > have different ways of working that would be hard to generalise like we did > with JUnit and TestNG I think. What are some of the candidates we might consider? > I think the best we could do is provide some abstractions around JavaScript > runtimes and JavaScript + HTML runtimes. This would allow different focussed > JavaScript testing plugins to code against these abstractions. At the moment, > most of the existing javascript testing plugins couple a testing framework > with a runtime. This is something users will want to control. They may even > want to use multiple, e.g. run their JS unit tests in IE, then FireFox etc. > > No actions to take at this stage, just sharing my thoughts so far. I think there's a huge overlap with javascript and c++. For everything you've written above, you could replace 'javascript' with 'c++' and still make sense. And I think whatever we do in the javascript space will benefit our c++ support, and vice versa. It all boils down to 1) no obvious conventions, so we either need to choose one, or abstract over several, and 2) much of the Gradle model is jvm-centric, even where it's abstract, so we need to detangle the model from the jvm, and model more stuff. In particular, the 'build my jar but pretend we're general-purpose' view of the world that our dependency model has has to go. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
