gmane.comp.programming.tools.gradle.devel

State of javascript stuff in master.

Luke Daley — 2012-05-21T22:40:34

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 als

source sets and non-jvm languages

Adam Murdoch — 2012-05-21T06:24:39

Hi,

Now that we're looking at adding some experimental javascript support, we now have 2 non-JVM languages we need to model. The current SourceSet model does not really work for these new languages (and there are problems with the JVM languages, too).

Some issues with SourceSet:

* Has a runtimeClasspath. This doesn't make sense when we're not targeting the JVM. C++ and javascript source do have runtime dependencies, but these dependencies do not end up as a classpath. For both C++ and javascript, we're also interested in building different variants, where each variant can potentially have a different set of resolved dependencies. Supporting variants also makes a lot of sense in the JVM world too (groovy-1.7 vs groovy-1.8, for example).

* SourceSetOutput effectively represents a set of JVM byte code. This is the same as the issue above. Modelling the compiled source as byte code doesn't make sense when we're not targeting the JVM. Also, each variant of the same source will generally end up with different

Project.getExtensions(Object) method?

Luke Daley — 2012-05-20T13:18:47

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

Gradle build.gradle

Russel Winder — 2012-05-18T15:05:34

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.

Using the tooling api for integration testing.

Luke Daley — 2012-05-17T13:54:39

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.

Improving JavaScript + Gradle

Luke Daley — 2012-05-16T20:12:18

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.

idea: “live tasks”

Luke Daley — 2012-05-16T19:48:34

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

markdown processor on forums changed.

Luke Daley — 2012-05-15T07:03:49

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.

Offering Help for Native Support

Shad0w1nk — 2012-05-13T02:20:42

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

tooling API dependencies

Adam Murdoch — 2012-05-07T00:40:57

Hi,

I've been gradually moving the things that the tooling API client uses out of the core project, into projects like base-services and messaging. The idea here is to decouple the tooling API client from core, so that we can start publishing core, and every project, with their real dependencies declared. Right now, only a handful of projects are published, and the meta-data declares only those dependencies that are needed in order to be used by the tooling API. This is to avoid dragging a whole heap of stuff into the tooling API (e.g. groovy, ant, ivy, http-client, and so on).

One question is to do with the real dependencies of the tooling API. At the moment, it drags in slf4j and guava. I'm not too concerned about slf4j, as this is effectively part of the interface between the tooling API and the client, as much as the tooling API itself is. Guava is potentially more of a problem, as its usage is internal to Gradle, and even though Guava seems pretty good at backwards compatibility, we are forcing a part

Can't build master.

Luke Daley — 2012-05-05T05:19:25

It's getting stuck at DefaultExecutorFactoryTest (in IDEA).

I've tried cleaning everything I can, and no luck. Is this just me?

progress logger

Luke Daley — 2012-05-04T17:12:35

Will ProgressLogger ever be made part of the public API?

https://github.com/gradle/gradle/blob/master/subprojects/core/src/main/groovy/org/gradle/logging/ProgressLogger.java

Surely a problem?

Russel Winder — 2012-05-04T08:59:35

Hi,

Guillaume has just enlightened me to
http://issues.gradle.org/browse/GRADLE-2170 and the fact that this means
it is impossible for Gradle to build Groovy.

If I were contemplating marketing Gradle and supposedly being this close
to release of Gradle 1.0, I would consider this to be leading to a
marketing nightmare:

Shiny new Gradle 1.0 is unable to build Groovy, the language on which
Gradle depends.

I can just imagine the fun on Reddit.

Is this a worry?

Russel Winder — 2012-05-02T19:18:26

When running "gradle wrapper" using master/HEAD of earlier today to
update from 1.0-rc-2 to 1.0-rc-3 I am getting:

Unable to load org.gradle.internal.nativeplatform.filesystem.jdk7.PosixJdk7FilePermissionHandler. Continuing with fallback.

Is the worrisome or reasonable to ignore?

Thanks.

Well this sucks 1.0-rc-3 broken...

Russel Winder — 2012-05-01T15:21:11

My project compiled and tested fine with 1.0-rc-2 with 1.0-rc-3 I get:

        :compileJava
        
        FAILURE: Build failed with an exception.
        
        * What went wrong:
        Execution failed for task ':compileJava'.
        > invalid source release: 1.7

This sucks:

1.  RC-2 worked fine, which means there are changes RC-2 -> RC-3 which
are not bug fixes aimed solely at turning the RC into the final release.
These are not RCs.

2. My build.gradle doesn't mention 1.7 anywhere.  I demand source
compatibility with 7 on the grounds that 6 is the past and everything
prior should not exist, I may be doing it wrongly, but see above.

Gradle Comms

Russel Winder — 2012-05-01T15:02:49

I assume that the Gradle Users mailing is considered a useless place for
communications about Gradle.  No notices about 1.0-rc-3.

buildSrc as a regular project

Adam Murdoch — 2012-05-01T01:06:22

Hi,

Something we want to do soon is to replace the buildSrc project with a regular project. There are a few motivations for this:

* To improve the user experience for those builds that need dedicated build logic. For example, currently the buildSrc project's 'build' target is used. But this runs all the tests and checks, whereas for 95% of the time, the user is only interested in compiling the classes. Or, currently we need to clean the buildSrc project when the Gradle version changes, whereas for regular projects we don't need to do this. Or, currently the buildSrc project does not end up in the IDE model, but would be included if it were a regular project.

* To allow build logic to both be published and used in the same build (but not in the same project, for now). This will mean that you can use your enterprise plugins in the same build that produces them. For example, you can use your custom release plugin to release your custom release plugin. We may use this in Gradle, too, when we add a plugin dev

Stopping Jetty

rnavarette — 2012-04-24T18:57:04

Hi Everyone,

Looking at a change made to AbstractJettyRunTask
(https://github.com/gradle/gradle/commit/5ed4fa1f4cad251424c2cb64917097f0e3dad51a)
by Adam Murdoch, it looks like the problem is in startJettyInternal().  The
following was added, right before the stop monitor is created/started:

if(daemon) {
    return;
}

So, whenever running in daemon mode, we don't create a stop monitor, and so
we can't stop a running server using the jettyStop task.  Does anyone know
of a reason for this, or is it a bug?

Background:

I'm having a problem stopping a jetty server that is running as a daemon. 
The server is started using jettyRunWar before running tests and then is
supposed to be stopped afterward.  The tasks are running properly and in the
proper order.

As far as I can tell, the jettyRunWar task is not paying attention to the
stopPort as configured in the gradle script.  If I monitor the build by
pausing before and after the jettyRunWar task, I can use netstat and see
that there is no listening port using t

Statement labels in build scripts

Peter Niederwieser — 2012-04-23T06:52:12

I have some code that detects use of labels in build scripts. I think it's
important to flag these because labels are often used accidentally, e.g.:

task foo {
  dependsOn: bar
}

Typically this will result in a no-op and thus can go undetected for some
time.

I propose to flag use of labels as an error. This is a breaking change, but
I think it's justified because virtually every use of labels will be
accidental. Alternatively, we could issue a warning. But I dislike warnings,
especially in such clear-cut cases. Thoughts?

Cheers,
Peter

--
View this message in context: http://gradle.1045684.n5.nabble.com/Statement-labels-in-build-scripts-tp5658497p5658497.html
Sent from the gradle-dev mailing list archive at Nabble.com.

Conventional location for build specific trust store.

2012-04-13T12:26:23

It might be nice to have a convention for a custom trust store to be used for a build. That way the store could be checked in.

We could consider this part of the environment just like JAVA_OPTS etc.

“Fix for” in JIRA.

Luke Daley — 2012-04-13T10:46:17

There are currently 73 issues scheduled to to be fixed in 1.0 according to JIRA.

http://issues.gradle.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+GRADLE+AND+fixVersion+%3D+%221.0%22+AND+resolution+%3D+Unresolved+ORDER+BY+due+ASC%2C+priority+DESC%2C+created+ASC&mode=hide

I think we should adopt the policy of not applying fix for versions until we start work on something and leave everything else unscheduled.