> Almost every ant file I've had the pleasure of working with in the wild is made badly (having to run things in specific order instead of depending on each oth

> Almost every ant file I've had the pleasure of working with in the wild is made badly (having to run things in specific order instead of depending on each other is a classic). Dependencies were a mess. Depend on A and B with both depend on C? C gets pulled in twice, build fails. Workaround? Hack up A to depend on B instead, and have your project depend on A. Surely adding a new dependency isn't supposed to involve mucking with the build files for half of your existing previously fine third party libs just to get the bloody thing building again - such that all dependencies are only referenced once, yet such that every library has it's dependencies indirectly satisfied by whatever it's been configured to depend on. I assume I was doing something wrong. I probably sunk a good week into consuming docs and trying stuff out to figure out exactly what. I still have no clue. My coworkers couldn't figure it out either. I wrote wrapper scripts - and later a full blown partial adb wrapper - to fix the silent deploy failures, after one too many hours of wasted debugging sessions (caused by debugging stale builds) made me crack. A few commands to check file sizes and timestamps... a few regular expressions to parse the results... a few debugging sessions when e.g. the installation defaults for "adb logcat" log output format changed between SDK versions... After reaching a similar snapping point for ANT, I took the slightly less drastic option of switching to gradle for the next Android project I tackled. I remember gradle being merely 50% as terrible as ANT. I seem to have successfully repressed many of my more detailed memories of dealing with both. Huzzah!