gmane.comp.programming.tools.gradle.devel

Re: source sets and non-jvm languages

Luke Daley — 2012-05-23T10:07:04

On 23/05/2012, at 2:31 AM, Adam Murdoch wrote:


Right. If we model a Java binary, we can model its runtime classpath and compile time classpath. If we express what we now call “project dependencies” in terms of these things then we can use this richer (than a configuration which is a flat bucket) in some very useful ways.

This also implies that we can react differently to dependencies on cpp libs vs js libs etc, which will be necessary.


Very compelling.


We might want to consider modelling QA. A QA step is not really a transform, it's more like a gateway. I'd still like to see this expressed in terms of the thing we are performing QA on though.

 Example output…

myBinary - compiling
myBinary - unit testing

No doubt, we'd get other useful things by having quality gates be a first class concept.


This would be very powerful. This would go a long way towards making temporary source dependencies trivial.


Agreed, this is a far more natural concept. I'd be surprised if more than 25% of people usin

Re: source sets and non-jvm languages

Adam Murdoch — 2012-05-23T01:31:10

On 21/05/2012, at 11:08 PM, Luke Daley wrote:


Exactly right.


"main" becomes a set that contains all the production source for the project, and "test" becomes a set that contains all the test source. There's useful stuff we can do with this information: build a production source zip, configure the IDE to point to all the production and test source directories, run inspections on the production source, etc. One question is whether it is worthwhile keeping an explicit grouping, or whether we just infer it.

In other words, do we have this structure:

sourceSets {
    main {
        cpp { … }
        java { …. }
    }
}

or this structure:

java {
    sourceSets {
         main  { …. }
    }
}

groovy {
    sourceSets { 
        main { … }
    }
}

cpp {
    sourceSets { 
       …
   }
}

The first option allows you to easily do common stuff with, say, production code or test code. The second option allows you to easily do common stuff for a given language, which is probably more useful. I guess t

Re: State of javascript stuff in master.

Luke Daley — 2012-05-21T23:16:29

Thanks for the pointer Eric.

On 22/05/2012, at 12:00 AM, Eric Berry <elberry-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

Re: State of javascript stuff in master.

Luke Daley — 2012-05-21T23:15:06




On 22/05/2012, at 12:07 AM, Ken Sipe <kensipe-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:


Intentionally, no. You'd have to add that one line yourself for the time being.

In the short term we are staying away from opinionated conventions.

Re: State of javascript stuff in master.

Ken Sipe — 2012-05-21T23:07:42

Did you wire the output of coffeescript to input of war?

Sent from my iPhone

On May 21, 2012, at 5:40 PM, Luke Daley <luke.daley-7036tVqVGhZZroRs9YW3xA< at >public.gmane.org> wrote:

Re: State of javascript stuff in master.

Eric Berry — 2012-05-21T23:00:45

Hi Luke,
    This does provide some conventional wiring, but I thought I'd throw
this out there anyway.
http://tellurianring.com/wiki/gradle/jslib

I created this plugin a while back. It needs updating to work with the
rc's, but there were folks using it.

Eric

On Mon, May 21, 2012 at 3:40 PM, Luke Daley <luke.daley-7036tVqVGhZZroRs9YW3xA< at >public.gmane.org>wrote:

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

Re: source sets and non-jvm languages

Luke Daley — 2012-05-21T13:08:54

On 21/05/2012, at 7:24 AM, Adam Murdoch wrote:


I'm just repeating you here, but trying to distill this down…

A SourceSet as we know it now couples source with one transform operation. We need to bust them apart and also make it one-to-many. That is, we need to isolate the concept of a “set of source” and “the operations that transform it”. The “set of source” bit should easy to generalise across languages. The model of a transform operation will likely have language/runtime specific characteristics (e.g. Java has a compile classpath, JavaScript does not).

It's not clear to me what the concepts of “main” and “test” become. Is the “main” source set the “main” Java and cpp code? Or does it only make sense to talk about the “main java”? I think we are probably going to need both. At the wiring level, I need the main “java” but it's feasible we will want to ask questions of all the “main” source. 

An implied challenge in this is creating a more powerful model that s

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

Re: Project.getExtensions(Object) method?

Adam Murdoch — 2012-05-21T00:59:15

On 21/05/2012, at 6:52 AM, Luke Daley wrote:


Maybe. The message you get from a ClassCastException says pretty much the same thing, from java 6 onwards.


Indeed. And for anything we dynamically mix in but that is really static in nature, such as extensions, or the DSL mapping. It would be nice to have a static view for this stuff somehow.

For example, it would be nice if we could automatically generate something like this from the JavaPlugin:

interface JavaProject extends Project, ExtensionAware, ConventionMappingAware {
    JavaPluginExtension getJava();
    void java(Closure cl);
}

Then, another plugin could implement Plugin<JavaProject> instead of Plugin<Project>, and Gradle would infer that the Java plugin needs to be applied and a Java-domain-specific view of the Project provided. This would be a nice way to decouple the API + implementation of plugins.

Same for other domain object types, where we statically mix in some of the dynamic stuff. This might grow so that the entire DSL mapping (which i

Re: Using the tooling api for integration testing.

Adam Murdoch — 2012-05-21T00:29:27

On 19/05/2012, at 8:41 PM, Szczepan Faber wrote:


It should. I'd say the test fixture would probably have a couple of execution modes:
* Run the build in-process (but in an isolated ClassLoader). That is, a more convenient but less accurate 'dev mode', similar in intent to our embedded GradleExecuter.
* Run the build in the daemon. That is, a less convenient but more accurate 'production mode', similar in intent to our forking GradleExecuter implementations.

You'd use the in-process mode if you wanted easy debugging.

The execution mode would be combined with several other capabilities, such as whether the client's classes are made visible in the build, and allowing the client to inject code to execute in the build.

We may or may not expose these capabilities outside the test fixture. I'm a bit reluctant to do so, but there might be some good use cases for making them available via the tooling API. Either way, I'd start by not exposing them.



--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP o

Re: Improving JavaScript + Gradle

Adam Murdoch — 2012-05-20T23:25:03

On 17/05/2012, at 9:20 PM, Luke Daley wrote:


That, plus the meaning we attach to the name: e.g. 'main' vs 'test'.


Quite possibly.

The use case I have in mind is where a javascript library expects a certain set of css rules have been applied, where the rules come from a css script provided as part of that library. And the css script in turns expects a certain set of images and other resources available at some relative urls, where the images are also provided as part of that library. That is, pretty much any widget/ui library. An example would be jquery-ui.

I can see a few ways to model this:
1. Introduce a 'web library' concept, which is simply a file tree of resources to be bundled in a web application. A javascript library like the above could be packaged [1] as a web library containing the javscript, css and other resources.
2. Introduce a 'javascript library' and a 'css library' concept (possible both as specialisations of 'web library'). The javascript library would depend on the css library at r

Re: Offering Help for Native Support

Shad0w1nk — 2012-05-20T21:22:37

Hi Adam,

These are very interesting information. Your current feature list for short
and soon-ish term is the most interesting for me (and for what I would like
to achieve with Gradle). I would really like to help for anything on this
list.

I may not be able to be much help for anything touching the dependency
management... I don't quiet understand it at this point. As for the other
feature, I could definitely give a hand. After using the NAR plugin, I could
recommend some idea to implement some feature:
- The static library could possibly be done by adding a linker layer were
you could control it by feeding command line argument to the linker directly
and possibly choose the compiler and linker to use independently.
- The support for more compiler/easier to implement newer one could be done
by having an idea of compiler/linker behavior that can be use/extend for a
specific toolchain. For example, some embedded cross-compiler toolchain are
using gcc with a different name (like arm-none-linux-gnueabi-gcc ).

Re: Project.getExtensions(Object) method?

Luke Daley — 2012-05-20T20:52:41

On 20/05/2012, at 9:42 PM, Adam Murdoch wrote:


Fair call.


I think so, just for error reporting. An exception saying that the object is not ExtensionAware would be better than a ClassCastException.

We've got the same problem for IConventionAware (when it goes public) & DynamicObject if that's going to be public at some point.

Re: Project.getExtensions(Object) method?

Adam Murdoch — 2012-05-20T20:42:13

On 20/05/2012, at 11:18 PM, Luke Daley wrote:


This doesn't really have much to do with a Project. I'd rather not treat Project as a bucket of utility methods.

ExtensionAware already exposes this information in the public API. Do we really need a static method to wrap a cast for you?


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

Re: Gradle build.gradle

Daz DeBoer — 2012-05-20T17:26:51

Fixed, thanks. The property is declared in Install.groovy, where it was
also spelled incorrectly.
Daz

On 18 May 2012 09:05, Russel Winder <russel-URxFuvIByzTe9xe1eoZjHA< at >public.gmane.org> wrote:

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?

Re: Using the tooling api for integration testing.

Szczepan Faber — 2012-05-19T10:41:56

The solution should also allow easy debugging.



http://ameba.apphance.com/introduction/hello-android

It's a testing framework for mobile apps, implemented as Gradle plugins. As
far as I know ameba's integ test coverage is dirvautomation is

Cheers!

---------------------------------------------------------------------

Re: Using the tooling api for integration testing.

Luke Daley — 2012-05-18T22:52:36




On 18/05/2012, at 5:15 PM, Szczepan Faber <szczepiq-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:


Who and how?

Re: Using the tooling api for integration testing.

Adam Murdoch — 2012-05-18T22:47:08

On 17/05/2012, at 11:54 PM, Luke Daley wrote:


There's a lot of overlap here between what we want to do for testing, and what we want to do for configuration injection. It's more or less the same problem: I have some code + state visible to me that I want to execute in a different context (ClassLoader and/or process), but I don't want to have to set any of this stuff up. I also want to be able to refer to some of the state from my original context, and sometimes get a result back.

In the case of integration testing, we want something like:
* A way to run a Gradle build and make the test's classpath visible to the build script. More or less what our in-process GradleExecuter does.
* A way to run a Gradle build isolated from the test's classpath, so that I can int test the real packaging. More or less what our forking GradleExecuter does.
* A way to run the entire test in the Gradle 'container', effectively as if the test were a build script.

This is the same problem that WorkerProcess solves, along with i

Re: Injecting wagon impls.

Peter Niederwieser — 2012-05-18T16:36:37

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.