What is the purpose of Gradle?

Question

I could use a little help understanding the concepts behind Gradle(plugin v 0.7) in the context of Android Studio 0.4.0. I have not used Gradle before and it's causing me nothing but problems. I'm not seeing its purpose/benefit because I don't know enough about it.

Some specific questions I have

1. What are these dependencies? I'm making a simple app with a navigation drawer, targeted to API 11+ where it should be natively supported. What dependencies could I be using?

2. What is a Gradle wrapper? What changes, if any, does it make to the completed application?

3. Why does Gradle need to be online constantly? I don't have internet access on my personal laptop when I'm at work. It's gotten to the point that I can't run or test my app because Gradle can't resolve some resource without internet access.

4. Why is it important that Gradle uses Groovy? I have searched around the internet and that tends to be something people like about Gradle but they don't usually explain why Groovy is important or what it does for an Android app.

Sometimes it's tough as an intermediate programmer as information tends to be overly simple or overly complex. Aside from my specific questions, any additional information you can provide would be useful. I'm not looking to debate the pros and cons of Gradle vs other tools that may do the same thing, I'd just like to know more about Gradle and its use so I can make informed decisions.

Thanks

Answer 1

Some of your questions are general in that they speak to why build tools are a good thing as a general matter. Others get to Gradle specifically. I will try to address both categories as succinctly as possible while trying to avoid others' nitpicking terminology.

Build tools like Maven, Gradle, SBT, Leiningen, etc. help to automate tasks that we would otherwise have to manually perform or "manually automate." I use the latter to describe what I used to do with Ant--writing custom tasks to compile, run, generate Javadoc, etc. so the tasks could be automated for the future. By conforming to conventions originally defined by Maven and adopted by the others subsequently (like putting your source in src/main/java), this becomes possible. If I follow the conventions, the build tool can compile, run, generate Javadoc, test, and everything else with minimal extra work.

Now to your questions (in order):

1. Another critical function of build tools is to reduce "jar hell" by managing dependencies in a consistent way across builds. I just specify which version of Apache Commons or Google Guava or Spring or Jackson I want (or even range of versions) and the build tool will download them and put them somewhere so they can be in the classpath and in the build if applicable (like a war file). I can also define scopes--like I want this dependency to be available at compile time but this other one only at runtime. Do I need to provide it explicitly, or will it be available? Stuff like that.
2. This is Gradle specific. As described here, the Gradle wrapper helps teams run Gradle without having to manually install Gradle while also maintaining consistency. Everyone uses the same version. Once you set it up, you never have to worry about it, and all the Gradle tasks you want to use are available via the wrapper, so you need not even care that it's there. You can choose to install Gradle directly and run it directly, but I rarely see the point.
3. This is general. I mentioned dependency management earlier. In order to fetch these dependencies, the build tool needs to get online where they are available from Maven Central or a bunch of third-party repositories. Another Maven innovation adopted by the others is repository management, so compiled artifacts are published to a repository according to convention so other projects can use them. Usually, you don't care about that. You just tell the tool you need a certain dependency, and it knows how to grab it because everyone follows the conventions. In situations where you are without internet access (something I am quite familiar with), your options are to just grab all dependencies when you are online and then optionally to set up a local Maven repository like Nexus or Artifactory to publish those artifacts to. Then you tell your build tool to look there as well as Maven Central, etc.
4. Maven is configured with XML, and that seemed really cool at the time. But there are two consequences. One is the configuration becomes very verbose. Another is that it gets hard to do custom things. You have to do everything declaratively in XML, which many find to be a pain. You configure plugins in XML, or you write your own and wrap it in a way Maven can understand and can be configured in XML. It is a lot easier and more powerful to do custom build stuff in code. Gradle chose Groovy for this because Groovy makes for nice DSL's and is really easy to learn for Java developers coming from Maven. SBT chose Scala and Leiningen chose Clojure because those build tools target those languages/platforms, so a Scala developer, for example, doesn't have to learn anything new to use SBT besides the DSL. But the broader point is that relying on code rather than XML has a lot of benefit.

Hope that helps.