2009/9/18 Adam Murdoch <[email protected]>
>
>
> Tom Eyckmans wrote:
>
>
>
> 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.
>
>
> I'm curious why you would want to do this? What use cases do you have in
> mind?
>
Exactly what you are suggesting below depending on the type of sources have
different tasks.
>
> Right now, source sets are untyped, so there is no distinction between
> which are production source sets and which are test source sets. I still
> think it is a good idea to type them somehow. My plan was to go slowly at
> this, and leave them untyped for the 0.8 release. Then, we can see how they
> are being used and what does and does not work, and address that in later
> releases.
>
Good plan
>
> I'm not, for example, 100% convinced that 'main' and 'test' is the right
> way to slice them. It feels to me we want a more descriptive slicing,
> something like:
> - library
> - application
> - web app
> - unit tests
> - integration tests
>
Totally agree, main and test should not be the only slices possible.
>
> We might allow multiple of the 'roles' to be applied to a source set. One
> option would be to allow plugins to be applied to a source set:
>
> source {
> main {
> usePlugin 'java-application' // (1)
> mainClass = 'org.gradle.BootstrapMain'
>
> usePlugin 'library' // (2)
> api {
> exclude '**/internal/*
> }
> }
> test {
> usePlugin 'library' // (3)
> }
> integTest {
> usePlugin 'integration-test' // (4)
> }
> }
>
>
I really like this idea, not sure if we need a new concept for the
'usePlugin' part, usePlugin is fine by me but it might be confusing for
starters to have usePlugin for sourcesets and toplevel in the build script
(project-reports plugin ?).
> Where
>
> (1) might add a dist task which creates a Zip containing launcher scripts,
> the runtime classpath, the main jar, plus anything from src/dist. Similarly,
> it might also add sourceDist, distTar, distTarGz and explodedDist tasks
> which do the same thing in different formats. It might also add the dist
> archives to the 'dists' configuration.
>
> (2) might add the javadoc task, and wire it up so it is included in the
> dist image. It might also add an apiJar task, and include that Jar in the
> 'api' configuration.
>
> (3) might publish the test classes api to the 'testFixtures' configuration,
> and the test classes impl to the 'testFixturesRuntime' configuration.
>
> (4) might add in an integTest task which runs against the main jar from the
> dist image, rather than the main classes dir.
>
> We might default to main { usePlugin 'library' } and test { usePlugin
> 'unit-test' }. Or maybe just test { usePlugin 'unit-test' }.
>
> We still get the distinction between production and test source sets, but
> we end up with a model that is much, much richer. We could also then fix up
> some odd things like the fact that the war plugin disables the jar task.
>
> 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/....
>
>
> This problem is independent of what we do with source sets, and affects
> anyone with large builds regardless of how the tasks get added.
>
> We really need some way to distinguish between the important tasks that are
> intended for a user to run from the command-line, and all the internal
> tasks. Personally, I like John's suggestion of having gradle -t show only
> lifecycle tasks by default, and maybe having gradle -t --all show all the
> tasks.
>
> Additionally, gradle -t might take a set of task name patterns, eg gradle
> -t compile*
>
> I like both.
> Or perhaps we should get some HTML project reports happening, which could
> potentially offer a better way of exploring and navigating the tasks of the
> build.
>
Perhaps a gradle console would be nice also
run 'gradle' to start the console
and be able to do:
cd gradle-core <enter>
-t <enter>
show only tasks of the gradle-core subproject
>
> Adam
>
>
