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 using project dependencies actually understand how they way.

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 there's no reason why we couldn't provide both views over the source.

Indeed. This probably doesn't meet that challenge yet (but 'has many concepts' is not quite the same as 'is not understandable'):

My thought is that we want to model the transformed output as concrete things, rather than abstract 'transformed source' things. That is, we should model things like jvm libraries, javascript libraries, reports, web applications, native binaries, and so on, each with type specific meta-data and configuration.

Each of these things should have a name, and a type. They would be Buildable, which gives us a place to define the processing pipeline to build the thing. You should be able to navigate to the inputs of each thing. I'd say a source set would be a kind of this thing, too.

This way, we have a graph of buildable things, and we know the inputs and outputs of each thing in the graph, plus the associated tasks to execute to transform the inputs things into the output thing. Sounds kinda familiar :)

This gives us a bunch of potential goodness:
* We introduce some concrete models for the things we actually build. This in turn leads to lots of goodness.
* We can short-circuit the execution and configuration of the tasks that build a thing whose inputs and outputs are up-to-date.
* We can log progress in terms of these things, rather than at the task level (eg. just log 'myBinary UP-TO-DATE' instead of each of the tasks that build myBinary).
* We can define the inputs and output of a project in terms of these things. Which means we can short-circuit the configuration of a project whose outgoing things are up-to-date wrt their input things. Or we can substitute in things pre-built elsewhere, and short-circuit configuring the target project.
* Incoming dependencies can be expressed in terms of these concrete things, instead of abstract 'modules' and 'configurations'. This, I think, helps with understandability.
* Works nicely with the 'keep this thing continuously up-to-date' feature we were discussing a few days ago.

So, the Gradle model becomes a graph of nodes that represent the things you want to build or use, with edges representing dependencies on other things. Things can either be built locally, or can come from somewhere else.

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

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

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 scales, but stays simple and understandable for the “compile my java code and run tests” case.

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

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 is also static) is mixed in. This would be very helpful for content assist in the IDE, for example. It would also allow alternative DSLs for static languages to be developed.

Not entirely sure how to implement something like this in a way that's convenient for use in the IDE. There's really only 2 broad approaches I can think of:
* Mix the stuff in to the target classes.
* Generate subclasses that mix the stuff in.

This is true for dynamic implementation, too, so we're really talking about moving the decoration from runtime to somewhere earlier in the development loop.


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

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 of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com

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 runtime, and the web application bundling would need to take care of honouring this dependency. This approach would model something like jquery-ui + separate themes.
3. Introduce a 'javascript library' concept with 2 usages: 'runtime' and 'deployment' [2]. The runtime usage defines the dependencies required to execute the script, e.g. for unit testing, and the deployment usage defines the dependencies required at deployment time. The web application bundling or deployment would need to take care of honouring the deployment time dependencies.

None of these are really mutually exclusive, in that we could do all 3. We probably don't want to do 1), except to maybe model css library is-a web library. We don't want to model a javascript library as a web library.

[1] packaging == the way (or ways) that a component is bundled into artefacts. A library may have multiple packagings. Some examples for a javascript library: as a stand alone script, as a file tree containing the script + css + resources, as a zip containing the script, dependencies, documentation, samples and so on.
[2] usage == some way that a component can be used. A library may have multiple usages. Some examples (from outside the javascript domain):

That's exactly the idea.

Dependencies would be declared using exactly the same DSL as we use to declare dependencies on java libraries, or c++ libraries. Javascript libraries would be published using exactly the same DSL as java libraries or c++ libraries. And into the same format as these things.

Of course, we're going to have to improve those DSLs to better deal with this. And we need to improve the schemes we use to publish to binary repositories.

I think it's really important that dependency management is in there from the start. We can improve any awkwardness over time.

For example, there's an 'on-boarding' problem, where most javascript libraries are not published to a binary repository in a well-defined format. But this is certainly not unique to the javascript world. It's also a problem in the c++ and java worlds, too.

However, these libraries are really only published in a handful of formats. We can probably come up with a repository type that can resolve the distributions at their origin, download them into the cache and munge them into the normalised layout appropriate for the type of library. We could even build an importer on top of this, that republishes these normalised distributions to the corporate repository manager. Perhaps we even publish some definitions for popular javascript libraries up on repo.gradle.org (i.e. don't publish the libraries, but publish enough metadata to download and use them from their origin).

There's all the benefits of declarative dependency management.

From a development point of view, I can declare a dependency on jquery, point the build at my corporate repository (or some public repository) and Gradle takes care of downloading jquery, injecting it into the correct contexts at test and runtime, and setting up the meta-data in the IDE.

From an enterprise point of view, there are many benefits: I don't have to open up the firewall to fetch this stuff. I can run each library through my procurement and audit process before making it available in the corporate repository. I have all the reporting goodness about which licenses and libraries are being used across my organisation. I can share javascript libraries and related assets in a controlled way between my teams. And so on.

In short, declarative dependency management >> checking stuff into the source tree.

Right. It would work in the same way as Java: A Java source set does not have any knowledge of web application, but when you tell Gradle that you're building a web application, it knows that certain compiled classes need to end up in a certain location in the resulting bundle. Same for Javascript. When you tell Gradle that you're building a web application, certain javascript source files need to end up in a certain location in the resulting bundle.

The key here is that these tools do 'the same thing', i.e. they are different implementations of an abstract lifecycle. The focus should not be on what the tools produce, rather than how they go about it.

There's a few aspects to this. We might do something like:
* Define an abstract lifecycle for javascript projects. For the most part, this won't be any different to the abstract lifecycle for java or c++ projects.
* Define a 'main' and 'test' source set, with source files living in 'src/$sourceSet/js'. Same for coffeescript.
* A source set may or may not be transformed before it is ready for execution. This might include compilation, concatenation, minification.
* Tests are executed against the transformed output of the main and test source sets.
* When building a javascript library, the transformed output of the main source set is published (plus meta-data).
* When building a web application, the transformed output of the main source set is bundled in the web application, at, say, '/js'.
* Start handling the concept of variants, to allow things such as a minified and non-minified variant to be built.

It's not any different in the java space. People use various kinds of compilers, code generators, and transformers to end up with the output that is ready to execute. Same with bundling (e.g. a regular jar, a fat jar, using jar jar, or an obfuscator).

I don't think there's really any practical difference. The abstractions are there in the Javascript world, and they're exactly the same ones that are in the c++ and java worlds:
* I write some code that I want someone to execute.
* I transform the source code into an executable form.
* I write some tests for it.
* I run the tests against the executable code.
* I package up the executable code.
* I publish the result, or deploy the result. Or both.
* My code has dependencies on other code.
* Some of these dependencies are written by other teams.
* I want to use an IDE to edit and execute my code

And so on.

It's exactly the same thing. My consuming a dependency is someone else's publishing, whether that person is using Gradle or some other tool or publishing manually. The above things form the contract between the publisher and consumer.

These concepts are not just applicable to dependency management, either. They're very much independent of whether you're sharing your output with another team. For example, my CI release build might build 3 variants of my web application, one for the development environment, one for QA, and one for production. My dev variant would bundle the non-minified script. The QA and productions variants would bundle the minified script.

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

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 ). Been
able to just specify the compiler behavior of gcc and changing the
executable name that is use directly in the build.gradle file could
definitely be really useful.
- The compled variant was probably well addressed in the NAR plugin with the
AOL properties (Architecture, Os and Linker). The only problem that I found
with this was the lack of flexibility in order to modify them through your
build script... but that could be address and changed :-)
- The support for C and any other language could be added by adding some
logic to configure a C, C++, ASM, D, etc environment within the gradle
script. Again, the NAR plugin address this by having "high level"
configuration that gets resolve into command line argument behind the scene
for each native language (they support C, C++ and Fortran). It's also a good
way to have cross-platform build script.

I'm sorry if I do a lot of comparison with the NAR plugin, but that was my
first and only great experience with a modern approach for managing native
project.

I'm pretty sure you have some though of your own on how to resolve and
address the different features. I could be a good idea, like you say, to
identify a strategy on how to implement these feature. Let me know how you
want to tackle all these.

Cheers,

Daniel

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

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 its early in-process equivalent inside InProcessCompilerDaemonFactory. So, we have the pieces for moving code from one isolated context to another. We'd need to shuffle some of this around so that there's a consistent interface regardless of whether the work is travelling to another process or not, add some convenience that understands closures, and wrap it in some public integration test fixtures.

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

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.