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 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")
  }

== Some interesting things ==

The rhino plugin will be the base for all JavaScript based tooling. Because I needed to use it as the basis for the other plugins, I put in some work abstracting over our WorkerProcess stuff to make it very easy to write a “RhinoWorker”. There might be some more generally reusable stuff for this for “blocking” workers (i.e. they receive a payload and return a result). This stuff is in https://github.com/gradle/gradle/tree/master/subprojects/javascript/src/main/groovy/org/gradle/plugins/javascript/rhino/worker

I ended up writing some HttpFileServer infrastructure for the envjs plugin. I read a lot of stuff saying that JavaScript unit testing is most reliable when you are accessing content over a HTTP server. This might be generally useful outside of the JavaScript context. This is in https://github.com/gradle/gradle/tree/master/subprojects/javascript/src/main/groovy/org/gradle/plugins/javascript/envjs/http

We'll want to support different scriptable DOM runtimes (e.g. different real browsers, or other simulated browsers) because some people won't be satisfied with envjs (though it's the simplest and most portable). To this end, I shook out some abstractions that would make this kind of thing pluggable. See https://github.com/gradle/gradle/tree/master/subprojects/javascript/src/main/groovy/org/gradle/plugins/javascript/envjs/browser and impl here https://github.com/gradle/gradle/tree/master/subprojects/javascript/src/main/groovy/org/gradle/plugins/javascript/envjs/internal

There's no direct support for any test frameworks yet. However, the envjs stuff is for that. With what's there now, it would be very easy to have automated javascript tests in a Gradle build. 

All in all I'm pretty happy with it. There's certainly potential there. Adding support for more tools written in JavaScript will be easy because of the Rhino infrastructure. The DOM runtime stuff is very interesting too. Users should be able to build support for specific test frameworks on top of this if needed. 

I don't plan to do anymore, unless I uncover bugs while putting examples and materials together.

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

* Has a compileClasspath. As above. Also assumes that we're actually compiling something. And that all languages share the same compile classpath.

* Has a (possibly empty) set of Java source to be compiled and included in the runtime classpath. This doesn't make any sense if there's no Java source  in the project.

* Has a set of resources to be included in the runtime classpath. This doesn't make any sense if we're not targeting the JVM.

There are also some language specific issues:

* Java should have a source language level, and an annotation-processor classpath.

* Groovy should have a source language level, and separate compile, language-runtime, compile-implementation, and transformer class paths. Scala should have something similar.

* The ANTLR plugin assumes we're generating a parser to run on the JVM. The tooling may run on the JVM, but the generated source may not.

* For each language, we should distinguish between generated and non-generated source.

I think I'd like to turn the current SourceSet/SourceSetOutput/GroovySourceSet/ScalaSourceSet/CppSourceSet into something like this:

* Interfaces that represent language-specific set of source, and specifies output-independent meta-data about the source: things like source directories and include/exclude patterns, compile and runtime dependencies, language level, and so on. So, we'd have a JavaSourceSet, GroovySourceSet, ScalaSourceSet, CppSourceSet, JavaScriptSourceSet and so on.

* An interface that represents a composite set of source files. This would be used to group language-specific sets to describe their purpose. This type would be used for 'sourceSets.main' and 'sourceSets.test'.

* Interfaces that represent runtime-specific set of executable files. These would be used to represent the output of the source sets, one per variant that we can build. For JVM languages, we'd use something that represents a tree of class and resource files. For native languages, we'd use something that represents a set of object files. For javascript, we'd use a JavaSourceSet.

* All of the above would extend Buildable. This better models generated source (but doesn't quite solve the problem on its own), allows a separate processing pipeline to be assembled to build the output for each variant, and allows us to handle executable files that we don't build, but need to bundle or publish.

* There would be some way to navigate between the outputs of a source set and the source set itself. Not sure exactly how that should look. Each language source set ends up built into one or more output. Each runtime output is built from one or more language source sets. Maybe the association is only by name.


--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com

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.

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.

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

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

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 particular version on the client. In addition, at some point we're going to want to reuse some of our remote resource/http transport/caching stuff in the tooling API, which drags in a bucketload of stuff.

Some options:
1. Avoid using any external stuff in the tooling API.
2. Keep the number of dependencies small, but expose them to the client.
3. Jarjar the internal dependencies into the base service jar or tooling API jar.
4. In a similar vein, offer a variant of the tooling API that embeds all its internal dependencies. Might make a nice plugin to offer API developers at some point.

Thoughts? I think we just go with 2. for now, and maybe 4. once our support for publishing variants is further along and/or we have more tooling API dependencies.

--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com

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

* To detangle project configuration from the project hierarchy. In particular, this required for parallel execution, so that projects can be configured in an arbitrary order, and across multiple JVMs and/or threads.

DSL-wise, there are 3 main use cases:
1. Declare that a given script depends on the build logic from some a project.
2. Declare that every script depends on the build logic from some project. Or there might be a convention for this, so that you give a project a particular name or put it in a particular directory, and it is automatically picked up as a build logic project.
3. Inject configuration to all projects, including those projects that are built during configuration time.

Use case 1
-------------

I think this is as simple as being able to add project dependencies to the build script's classpath configuration:

buildscript {
dependencies { classpath project(':buildLogic') }
}

When we simplify the DSL for applying plugins, this might become something like:

apply project: ':buildLogic', plugin: 'my-custom-plugin'

Implementation-wise, the configuration phase would look something like this:

1. Queue up the configuration of each project, in parent-first order (like we do now).
2. For each project, if not already configured, then execute the project's build script.
3. For each script that is executed:
* Execute the buildscript { } section of the build script.
* For each project dependency in the build script classpath, recursively configure and build the target project. Fail if the target project is currently being configured.
* Resolve the build script classpath and execute the script.
* For each call to evaluationDependsOn(), recursively configure the target project. Fail if the target project is currently being configured.
4. For each project that is built during configuration:
* Configure the project as above
* For each project dependency required to build the project, recursively configure the target project. Fail if the target project is currently being configured.
* Add the tasks that build the runtime class path for the project to the DAG.
* Execute the tasks.

I think this boils down to some changes to dependency resolution:

During the configuration of a project:
1. When a Configuration is resolved, for each project dependency we trigger configuration of the target project and building of its artefacts.
2. When a Configuration's buildDependencies are queried, for each project dependency we trigger configuration of the target project.

At other times (e.g. task execution):
1. When a Configuration is resolved, for each project dependency assert that the target project has been configured and the artefacts built. It's an error if not.
2. When a Configuration's buildDependencies are queried, for each project dependency assert that the target project has been configured. It's an error if not.

And the same kind of thing for task dependencies:

* When a task's dependencies are resolved during configuration, trigger the configuration of the target project.
* When a task's dependencies are resolved at other times, assert that the target project has been configured.

Some open issues:

* Currently, the buildSrc classes are available in the settings script. This would not be the case if a regular project is used. Some possible solutions:
- Use an external script for any shared logic.
- Allow the settings script to add projects in it's settingsscript { } section, and resolve configurations as above.
- Move the logic to an external project, and allow plugins to be applied to the Settings object.
- Allow build scripts to add projects.
- Chop your settings script into 2: one which defines the build logic projects, and a second one that declares a dependency on that project and uses it to define the remaining projects.

* Tasks can be executed before the DAG is fully populated, and before the 'DAG ready' event has been fired. This means that some conditional configuration may not have been executed when these tasks are executed. Introducing build types might be an option here, so that the conditional stuff is applied much earlier in the configuration phase.

* Projects can be configured and tasks executed before the parent project has had a chance to do configuration injection. More on this below.

Use case 2
------------

I like the idea behind the buildSrc project: you just put your build logic in a certain place, and it is just made available. It would be a shame to lose this. I wonder, however, if we really need this, assuming we can reduce the boilerplate for adding a project dependency to a build script classpath down to a single statement. We might also tackle this by making script 'plugins' work more like plugins, so that something like:

apply plugin: 'my-plugin'

might come from a compiled class from another project, or might apply $rootDir/gradle/my-plugin.gradle (or whatever).

This way, plugins are provided by the environment and the consuming script doesn't care where they come from. What is currently in buildSrc would turn into one of the following:
* A regular project in some external build, with plugins published to a repository.
* A regular project in the same build, with plugins built locally.
* A script in some conventional (or declared) location.

Use case 3
------------

The current approach of using allprojects {} and friends for configuration injection isn't going to work, as the build logic project will potentially have been configured and built before the injecting script has a chance to execute.

There are a couple of existing approaches that would work (but are a bit awkward):
* Move the shared logic to a script, and apply it from various locations
* Move the shared logic to a plugin in a second build logic project, and depend on it from various locations.

The existing configuration injection methods have some other problems. First, these methods guarantee that the code is called for every project, and that every project is configured. However, this stops us doing some things:
* Skip the configuration of projects that aren't relevant to the current build. Eg in the Gradle build, don't configure all the plugin projects if I'm running the unit tests for core.
* Short-circuit the configuration of projects whose outputs are up to date. Eg in the Gradle build, when I'm working on the c++ plugin, don't configure all the core projects when none of their source or configuration has changed.
* Use compatible pre-built artefacts from a binary repository, rather than configuring the projects and building their artefacts. Eg in the Gradle build, when I'm working on the c++ plugin, just get the rest of the binaries from the CI server (not a great example, but you get the idea).

Second, these methods guarantee that the code is always called in the same context. This stops us doing some of these things:
* Building separate chunks of the model concurrently.
* Building the model across multiple JVMs or machines.

So, I think we need a new DSL here. Some options:

1. Just change the injection methods, so that they drop these guarantees.
2. Change the injection methods so that they have 2 modes. Allow a build script to declare which mode it needs.
3. Add new injection methods, with different names to the existing methods.
4. Use scripts in conventional locations. So, perhaps $rootDir/gradle/allprojects.gradle is applied to each project before it is configured.
5. Allow configuration to be injected from the settings script (with the new semantics).
6. Add a new type of build script, with injection methods that have the same names as the existing ones, but with the new semantics.

Option 1) is not really an option. Options 2), 3) and 6) don't solve the build logic project problem. Personally, I like 5), because it detangles the build configuration from the root project. What is interesting about this option is that it allows you to have a single .gradle file for an entire multi-project build, that both defines the projects and injects configuration into them.

An open issue is exactly what the semantics of the injection methods would be. They're going to have to deal with the fact that the configuration code may end up running in various different JVMs. This has some implications as to how values are shared across projects, e.g. a calculated version.

Migration
----------

I think eventually we want to get rid of buildSrc altogether. The plan would be to implement the above use cases as experimental features, leaving buildSrc alone. Then, we should shake out the new configuration mechanism further with some of the parallel execution and partial configuration features. Once we're fairly happy with how this looks, we would deprecate the buildSrc project, and later remove it.

--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com

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 the number i set for stopPort. So,
when jettyStop runs, it doesn't do anything because there is no monitor
listening on the expected port.

I think that most users wouldn't notice this issue because the server is
properly stopped when the gradle script finishes execution. In our case
though, we start and stop multiple jetty servers in the course of a build to
run different sets of acceptance tests. Whenever the second set of tests
starts (in whatever order we run them) they fail because the webapp is not
deployed properly to the server due to the previous server not shutting
down.

Thanks,
ray

--
View this message in context: http://gradle.1045684.n5.nabble.com/Stopping-Jetty-tp5662999p5662999.html
Sent from the gradle-dev mailing list archive at Nabble.com.

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.