5 ms·

> The only thing worse than gradle is ANT, which it replaced. What's wrong with ant? I liked it.. It was simple to understand for the most part. It also made

by rifung 10y ago

> The only thing worse than gradle is ANT, which it replaced. What's wrong with ant? I liked it.. It was simple to understand for the most part. It also made it easy to develop without an IDE, although I'll admit I don't know how easy it is now as I stopped doing Android a year ago

stuaxo 10y ago
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). With Android, they seemed to change the build files every minor release (my info may be out of date here).
- MaulingMonkey 10y ago
  > 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!
flukus 10y ago
The problem I had with it was all the crap google would do automagically, not really an ant problem, but building android software is a mess: http://flukus.github.io/2014/08/19/2014_08_19_Android-Take-back-your-builds/ http://flukus.github.io/2014/08/19/2014_08_19_Android-Take-b...
izacus 10y ago
And that's about all it does. Gradle has proper dependency managment with Maven repository support (add one line and your library is in, no fsckery with JARs and whatnot), has scripting in an imperative language instead of craziness of XML (we use it to automate releases, uploads, Git commits, etc.) and really good plugin support. It's also slow as arse unfortunately.
- pjmlp 10y ago
  Except many of us are comfortable with XML "craziness" and see no value in Gradle besides wasting battery.
- rifung 10y ago
  Ah I agree on the dependency part. I suppose it was easy enough for me to just pull in the jars but I suspect my projects had rather simple dependency needs. Sounds like what you were doing was much more involved! I appreciate the reply
- flukus 10y ago
  So it's like make then? We've had tools to do this for 30+ years.

by rifung 10y ago

stuaxo 10y ago

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). With Android, they seemed to change the build files every minor release (my info may be out of date here).

MaulingMonkey 10y ago
> 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!

flukus 10y ago

The problem I had with it was all the crap google would do automagically, not really an ant problem, but building android software is a mess: http://flukus.github.io/2014/08/19/2014_08_19_Android-Take-back-your-builds/ http://flukus.github.io/2014/08/19/2014_08_19_Android-Take-b...

izacus 10y ago

And that's about all it does. Gradle has proper dependency managment with Maven repository support (add one line and your library is in, no fsckery with JARs and whatnot), has scripting in an imperative language instead of craziness of XML (we use it to automate releases, uploads, Git commits, etc.) and really good plugin support. It's also slow as arse unfortunately.

pjmlp 10y ago
Except many of us are comfortable with XML "craziness" and see no value in Gradle besides wasting battery.
rifung 10y ago
Ah I agree on the dependency part. I suppose it was easy enough for me to just pull in the jars but I suspect my projects had rather simple dependency needs. Sounds like what you were doing was much more involved! I appreciate the reply
flukus 10y ago
So it's like make then? We've had tools to do this for 30+ years.