2009/9/16 Adam Murdoch <[email protected]>
>
>
> 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?
>
I also find it really ood to have to specify the language here, I thought we
planned on having a distinction between main and test source sets and have
the compile and compileTests as tasks that compile all main source sets and
compileTests compile all test source sets.
To limit the gradle -t output we need to have a way to segment the output,
like for synthetic tasks for source sets only show the global tasks that
execute all of the main/test source set compiles/tests/....
And allow for example:
gradle -t main
with main being the main source set and show all the synthetic tasks for
that source set when asked for like this.
> 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
>
>
>
