Steve Appling wrote:
Adam Murdoch wrote:
Steve Appling wrote:
I have not been paying enough attention to the source set changes,
but one item caught my eye today that I really would like to see
changed.
I fully support the concept of source sets where you have groups of
source divided by function: main, test, integTest, etc. This is great!
I don't, however, like the inclusion of the language as part of the
task name. I don't think that the user should have to know whether
to call compileGroovy or compile or compileScala. I have been bit
several times now by calling project:compile and nothing happens.
There is a compile task, it just does nothing. I didn't know to
call project:compileGroovy.
I'm curious why you're calling the compile task from the
command-line? Not that what you point out above isn't a problem, I
think it is. If we know what your use case is, we can come up with a
solution.
The first time I ran into this was a dependency problem in the
gradle-ui project. It has:
compileTest.dependsOn project( ':gradle-core' ).compileTest
This is now broken because "compileTest" doesn't do anything. It
needs to now be compileTestGroovy. I didn't know that and it took me
a while to puzzle out.
Aside - Perhaps you could suggest a better way to do this. We needed
to have the tests in the gradle-ui project depend on the tests in the
gradle-core project. It seemed that this should be easier, but we
solved it with the above task dependency and a configuration of:
testCompile files(project( ':gradle-core'
).dependencyProject.source.test.classesDir)
I think the best option is for projects to consume gradle-core's test
classes using exactly the same mechanism as they do for gradle-core's
production classes. Currently, we publish a jar containing the
production classes to a configuration, and the other projects pick this
up using a project dependency. We should do the same for the tests,
though we might just publish the test classes dir, rather than bothering
to jar them up.
Then, the auto-wiring will pick up the correct dependencies, without
anyone needing to explicitly add dependOn compile or compileTestGroovy
or whatever.
Something like:
In gradle-core:
configurations {
testFixtures
testFixturesRuntime
}
dependencies {
testFixtures source.test.classes, source.test.compileClasspath
testFixturesRuntime source.test.runtimeClasspath
}
In gradle-*
dependencies {
testCompile project(path: ':gradle-core', configuration: ':testFixtures')
testRuntime project(path: ':gradle-core', configuration:
':testFixturesRuntime')
}
Later I noted that the gradle-ui/src/main/groovy only contains java
files and I wanted to compare the compile speed for building this
under groovy and under java. I was running gradlew :gradle-ui:compile
and comparing the performance with a java directory and a groovy
directory. Surprisingly the groovy one was faster - but only because
the compile task doesn't do anything when you have the groovy
directory. After comparing using the correct tasks I saw that it
compiled about 1.5 sec faster when under the java directory. I plan
to check it in this way. This isn't a common thing to do, but it
pointed out an area of confusion to me. I do think that people call
compile (and certainly test) directly and they shouldn't have to
specify the language.
Perhaps we should rename 'compile' to 'compileJava', and add a 'compile'
task which depends on {compileJava, compileGroovy, compileScala} as
appropriate?
This would also clean up the output of gradle -t, and let you do gradle
-x compile.
Before we release 0.8, I think it would be good to use source sets
in gradle's own project for integration Tests. I think our own
build.gradle is often used as an example for others. It is actually
a little sad how complicated it is now.
Indeed. There's a few things we've discussed recently which will
clean it up, but I think they're post-0.8 things:
- A java application plugin
- An aggregating project plugin
- Moving documentation + samples into their own subproject
- Task dependency auto-wiring
Adam
I think all of those post 0.8 items will help, but I would like to see
at least the integration tests use source sets in 0.8. That should be
straightforward, but I'm not sure I understand source sets well enough
to do it now :(
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
