Thanks for this info, and also thank you very much for the hint at the bug
report that you gave me on IRC yesterday.
At least I guess "adam" was you.
Cheers,
Joern.
On 03.08.2010, at 10:36, Adam Murdoch wrote:
> On 1/08/10 3:30 AM, Joern Huxhorn wrote:
>> I'm a gradle newbie and have just started to move my projects over to gradle
>> 0.9 Preview 3
>>
>> I have the following in my master gradle file:
>>
>> allprojects {
>> group = 'de.huxhorn.sulky'
>> version = '0.9.12'
>>
>> }
>>
>> subprojects {
>> apply plugin: 'java'
>> apply plugin: 'eclipse'
>> apply plugin: 'maven'
>> apply plugin: 'project-reports'
>>
>> sourceCompatibility = 1.5
>> targetCompatibility = 1.5
>>
>> repositories {
>> mavenCentral()
>> }
>>
>> dependencies {
>> testCompile libraries.junit
>> testCompile libraries.'slf4j-api'
>> testCompile libraries.'logback-classic'
>> }
>>
>>
>> jar {
>> manifest.attributes provider: 'gradle'
>> }
>>
>> task release(dependsOn: [clean, build.taskDependencies])<< {
>> println 'Finished release.'
>> }
>>
>> gradle.taskGraph.whenReady {taskGraph ->
>> if (!taskGraph.hasTask(release)) {
>> version = version+'-SNAPSHOT'
>> }
>> }
>>
>> }
>>
>> This should automatically append "-SNAPSHOT" to the version of my files if
>> release is not contained in the tasks. If I use "release" then it should
>> perform a clean build. The version part works but calling
>> gradle release
>> explodes since clean is executed after build.
>> gradle clean release
>> on the other hand, works.
>>
>> What am I doing wrong?
>
> Nothing. Gradle treats the dependencies of a task as unordered, and will
> execute them in any order it likes. This order happens to be alphabetical at
> the moment, but will almost certainly change when we introduce parallel
> builds. So, in your case, Gradle will execute the dependencies of release
> alphabetically, which happens to be execute build and then clean.
>
> We want to fix this before the Gradle 1.0 release. There's a few solutions to
> this problem which have been discussed, not sure at this stage which one we
> might do (though they are not necessarily mutually exclusive):
>
> - Introduce into the Java plugin the convention that 'clean' must run before
> any other task.
>
> - Introduce the concept of destructor tasks. This would complement the idea
> that some tasks create files (ie have output files). Gradle would run
> destructor tasks for a given file before the creator tasks. The 'clean' task
> would be annotated as destroying the build directory, and Gradle would
> schedule this accordingly.
>
> - Introduce the concept of build types or workflows. These would probably be
> a special type of task which represent a workflow, or sequence of tasks which
> must be executed in a specified order. You might use these to define a
> release build, CI build, deploy build, developer build, whatever.
>
> - Similar to the above, is to introduce a type of task dependency which is
> ordered, so that you can mix and match ordered and unordered dependencies for
> any given task.
>
> Until we do fix this problem, a workaround is to add a dummy task called
> something like 'aClean' which depends on 'clean', and change 'release' to
> depend on 'aClean'.
>
>
> --
> Adam Murdoch
> Gradle Developer
> http://www.gradle.org
> CTO, Gradle Inc. - Gradle Training, Support, Consulting
> http://www.gradle.biz
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
