Order of tasks run from imported ant build

Old Forum Archive
1

I am experimenting with using gradle’s ant import feature as the first step in migrating an old, large, and somewhat broken ant build to gradle. The problem I am having is because of bugs in this ant build and not because of bugs in gradle, but I’m sure it’s a problem others must have. In particular, there are cases in our ant build in which one task doesn’t declare a dependency on another task when it should, but the build works by luck because of the order in which ant happens to run the tasks. For example, if you run ‘ant x’ with this build.xml:

<project>
 <target name="x" depends="b,a"/>
 <target name="a"/>
 <target name="b"/>
</project>

ant says:

Buildfile: /tmp/z/build.xml
  b:
  a:
  x:
  BUILD SUCCESSFUL
Total time: 0 seconds

but if you create this build.gradle:

ant.importBuild "build.xml"

and run ‘gradle x’, you see

:a
:b
:x

It seems that ant is running the independent dependencies of x in the order in which they were listed in the depends task (b and a) where gradle is running them alphabetically subject to the topological sort of the DAG.

There’s no question in my mind that what gradle is doing is correct. It is clearly correct. After all, who says there isn’t another task “y” that depends on “a,b” in that order instead? Even ant doesn’t guarantee the order in which two independent tasks will run even if it happens to do it in a particular way.

At the same time, if it so happens that “a” fails unless “b” is run first and “a” fails to declare a dependency on “b”, then the imported build will fail even if the original build succeeds, and this creates an impediment to migrating.

Is this a pattern people have run into before? Is there a standard workaround in place? Has anyone produced anything that will look at an ant build figure out what order the targets would be run in, and compares this to the order gradle would run the imported tasks in given a particular task? In this particular instance, it’s pretty easy to see that if the “x” task is given on the command line, ant and gradle would behave differently. Getting a list of such cases might help someone trying to fix the old build to identify places where dependencies might be missed.

If there’s nothing currently in existence to help with this, I’m sure I can do the analysis on the old build, but I thought I’d ask before I reinvent the wheel.

2

It’s a known limitation, caused by the fact that Gradle has no equivalent to Ant’s soft dependencies feature. Depending on the circumstances, it’s sometimes possible to overcome this problem by adding regular dependencies on the Gradle side. That’s because Ant’s soft dependencies are often abused and used in places where they aren’t needed (without the build author even being aware of the feature).

3

That’s what I figured, and that seems perfectly fine.

I would like to suggest that a note about this be added to the documentation in the “Importing an Ant build” section. What’s the best way to make that suggestion? Is mentioning it here sufficient, or should I open a ticket? Or do something else?

4

Adding a note to the docs is a good idea. Best way to get it done is to send a GitHub pull request.