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 3I 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
