On Thu, Apr 8, 2010 at 8:19 AM, Geronimo M. H. <[email protected]> wrote:
> Hello,
>
> I tried to create a release task like that:
>
> task release {}
> release.dependsOn 'clean', 'build', 'srcWDDist', 'srcWoDDist'
>
> and I got this result executing gradle:
>
> $ fgradle clean
> :clean UP-TO-DATE
> :SRLibAppBase:clean
> :SRLibDA:clean
> :SRLibGui:clean
> :SRServiceManager:clean
> :SRSrvSample:clean
> :SRStarter:clean
>
> BUILD SUCCESSFUL
>
> $ fgradle release
> :compileJava UP-TO-DATE
> :processResources UP-TO-DATE
> :classes UP-TO-DATE
> :jar
> :srcWDDist
> :srcWoDDist
> :assemble
> :compileTestJava UP-TO-DATE
> :processTestResources UP-TO-DATE
> :testClasses UP-TO-DATE
> :uploadArchives
> :test UP-TO-DATE
> :check UP-TO-DATE
> :build
> :clean
> :release
>
> BUILD SUCCESSFUL
>
> What I don't understand:
> - after running clean, how could compileJava be up-to-date?
> - all 4 task, that my release task depends on, have no relations to each
> other, how can I specify, that "clean" should be executed before "build",
> without specifiing that "build" depends on "clean"?
>
> I can not imagine a development cycle, where clean makes sense to be
> executed
> after the build-step. Doesn't need the tasks a priority or the like?
>
We have discussed ordering of task dependencies quite a bit in the past. It
is a shallow solution that does not work for more complex scenarios. See the
discussion in: http://jira.codehaus.org/browse/GRADLE-427
Gradle does not offer anything better yet though. What you can do for now as
a not so nice work around is to rely on the alphabetic ordering of tasks. So
in your case you would need to add a task like a_clean, which will be then
executed before build.
There are a couple of solution we have in mind to provide solution for this
scenario.
- If the input/output model is richer we would know that clean destroys
where other tasks add to.
- We will provide more ways to specify rules for the DAG, like: if clean is
to be executed, make it an initializer of any other tasks.
- Hans
