State of javascript stuff in master.

The two day spike is over, here's what we got.

There are 5 plugins…

* The “javascript-base” plugins adds a “javaScript” extension and provides predefined repos
for our JS repo (http://repo.gradle.org/gradle/javascript-public/) and Google's.
* The “rhino” plugin adds support for using RhinoJS as a JavaScript runtime. It configures a default
rhino dependency, and provides a bunch of reusable infrastructure for forking rhino based worker
processes which is used by all of the following plugins
* The “coffeescript-base” plugin adds support for compiling CoffeeScript source into JavaScript
(via a Rhino worker process). It also provides a default coffeescript.js dependency (from our JS repo)
* The “jshint” plugin provides static analysis of JavaScript code (via a Rhino worker process). It
also provides a default jshint.js dependency (from our JS repo)
* The “envjs” plugin provides a completely headless scriptable DOM runtime (i.e. a simulated
browser) (via a Rhino worker process). It also provides a default envjs.js dependency (from our JS repo).

I intentionally steered clear of providing any conventional wiring regarding project structure (i.e. no
source sets or predefined tasks). For example, if you want to compile some coffee script you need to wire
this together yourself right now, but it's pretty straightforward.

  apply plugin: "coffeescript-base"

  repositories {
    mavenCentral()
    add javaScript.gradlePublicJsRepository
  }

  task compileCoffeeScript(type: CoffeeScriptCompile) {
    source fileTree("src/main/coffeescript")
    destinationDir file("build/compiled/js")

source sets and non-jvm languages

Project.getExtensions(Object) method?

Should we add this as the public typed API for getting the ExtensionContainer of decorated objects?

--

-- 
Luke Daley
Principal Engineer, Gradleware 
http://gradleware.com

Re: Injecting wagon impls.

You can use any wagon by setting `mavenDeployer.configuration`. At least
that's how it is supposed to work. (We should definitely rename this
property.)

Cheers,
Peter

--
View this message in context: http://gradle.1045684.n5.nabble.com/Injecting-wagon-impls-tp5709797p5709800.html
Sent from the gradle-dev mailing list archive at Nabble.com.

Gradle build.gradle

The two install tasks in the Gradle build.gradle have lines:

    installDirProperyName = 'gradle_installPath'

which is t-less when it shouldn't be.  Unless there is the same spelling
error somewhere else I don't know how this works.  Anyway time for t.

--

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder <at> ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@...
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

Using the tooling api for integration testing.

This is not really practical right now, unless I'm missing something.

We need a convenient way to inject the classes under test. I spent a little time looking at this and couldn't
come up with a satisfactory strategy.

I had to deliver some code to do this, so fell back to using GradleLauncher.

--

-- 
Luke Daley
Principal Engineer, Gradleware 
http://gradleware.com

Improving JavaScript + Gradle

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.

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. 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.

--

-- 
Luke Daley
Principal Engineer, Gradleware 
http://gradleware.com

idea: “live tasks”

I've been surveying the Javascript tooling landscape recently.

One thing that's very common is to have daemon processes that watch files and perform some action on change.
Consider the case where you want to write CoffeeScript, but compile it down to JavaScript and deploy that.
During the development cycle, you want something to do this compilation as soon as you save a change so that
when you refresh the browser you see the change (because the javascript has been updated).

With javascript, there can be a few different processing phases. e.g. CoffeeScript → JavaScript →
compressed JavaScript → bundled JavaScript (combined into one file). You way want to use this final
output during the development process.

Another case for this is continuous testing. A lot of the javascript testing tools require a html
bootstrapping page that does something like set the test classpath and kick off the tests. You really want
this to be generated, managing the “classpath” dynamically.

All of the maven javascript tooling plugins that do this hand roll their own daemon process management,
which is usually just starting the process. 

There are non javascript cases for this too. 

For war development, it would be nice to have something like “processResources” run whenever an input
file changes (as they may be filtered). For our html slides, I'd like them to be compiled to html whenever I
changed the input markdown.

It strikes me that we may be able to come up with a solution that could turn almost any task into what I'm
calling a “live task”. Since we know what the inputs are we could monitor them and trigger the task when
they change, no matter what the task is doing. I suspect that would be the easy part though. Managing and
providing control over these daemon processes would likely be the most costly to implement, as well as
providing insight into what they are doing. 

Rather exciting possibility though. If I'm working in a java module with unit tests, I could just
“liven” the test task for that module and achieve continuous testing (granted, you'd want to be
plugged into a power source if you did this). I'm not aware of another tool that provides this feature
generically, for any kind of task.

--

-- 
Luke Daley
Principal Engineer, Gradleware 
http://gradleware.com

markdown processor on forums changed.

Heads up…

I had to swap out the javascript markdown processor we use on the forums because I found some corner cases the
one we were using didn't support.

Let me know if you see any weird formatting in the coming days please.

--

-- 
Luke Daley
Principal Engineer, Gradleware 
http://gradleware.com

Offering Help for Native Support

Hi,

I started looking at Gradle more actively about 2 weeks ago. In fact, I am
more interested in the native (C/C++) portion that the Java. In the pass, I
used the Maven Nar plugin for building native on Windows desktop and on an
embedded Linux system. Unfortunately, Maven has there problem (mainly
flexibility) and Nar plugin doesn't really give official support for
enterprise. Looking at Gradle, you seem to be well place to give enterprise
level support. Sadly, the native capability is needed and looking at it more
in dept I can really see that it's in an experimental phase.

Luckily, I would really want a tool like Gradle to work with native build.
Poking around in the forum, I can see that you actually have plan to bring
native support to Maven's Nar plugin level. I would like to help you achieve
this objective. In order to do so, I would like to know more information
about the cpp plugin and design choice. I would like to know the following:
- What is the high level idea behind the class architecture of the cpp
plugin?
- Did you use Maven's Nar plugin as a reference and, if yes, what portion
did you use (or plan to use) and what portion do you think of doing better?
- What is the future plan of cpp plugin?
- Why do cpp plugin has it's own way of defining the source set and the
configuration? Wouldn't it be simpler if the source set was define exactly
like Java and Groovy project?
- Why is there two plugin (cpp-exe and cpp-lib)? Wouldn't it be simpler if
the configuration was define in the global configuration and just specify
the type (lib or app)?

I know that I may no have a clear view of the architecture but from what I'm
seen, you guys seems to know where your heading. I would be great if you
could share this view so I can do what I can to contribute on this section.

Thanks,

Daniel

--
View this message in context: http://gradle.1045684.n5.nabble.com/Offering-Help-for-Native-Support-tp5707874.html
Sent from the gradle-dev mailing list archive at Nabble.com.

tooling API dependencies