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)
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.
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 :(
--
Steve Appling
Automated Logic Research Team
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
