4 ms·

I'd say Gradle is the least awful of the 3 major build systems. Ant degrades into an unmaintainable mess as soon as any complexity enters the system. XML is a

I'd say Gradle is the least awful of the 3 major build systems. Ant degrades into an unmaintainable mess as soon as any complexity enters the system. XML is a horrible scripting language, simple imperative constructs are very awkward (loops/variables/conditionals). Maven also suffers from XML hell, but at least it has dependency management. I've used gradle extensively and it is quite difficult to figure out what is going on. Using a debugger would be nice, but it simply doesn't work. Gradle is terribly slow on a big project, the update checks are the main culprit. They should be done automatically in the background to alleviate this pain. Since gradle is compiled rather than interpreted, calling code in the project being built is difficult and convoluted. For example, if I want to call a DBUtil.cleanDB() method in my java code I can't reference DBUtil in my gradle script as it hasn't been built yet and the Gradle script won't compile. If gradle was interpreted this problem wouldn't exist.... I find the DSL unintuitive and the inability to specify the order of tasks execution is always a sore point. On the positive, at least it's a language, not XML. I have never understood the java world's obsession with XML and forcing it in directions never intended. This XML obsession has led to java being a major laggard in automation tech. Java devs do many things manually that a Ruby/Python dev would be horrified at....

tieTYT 12y ago
> Maven also suffers from XML hell, but at least it has dependency management. I don't find it that bad. The nice thing about it is how my IDE will auto complete almost everything and it should be possible to validate it without even using an IDE, as it has a schema. I agree with your complaints about Ant. The thing I was hoping gradle would give me is the ability to write tests for my build. EG: I want to have more confidence that my maven filtering is working the way I want it to. But it sounds like gradle isn't built with that in mind. Considering that groovy is dynamically typed, if my IDE doesn't auto complete (maybe it does) I think it's possible to make the argument that Maven is the least awful of the 3. At least the maven XML has a schema. I don't need yet another way to make a mistake in my build script (ie: typing issues). > Java devs do many things manually that a Ruby/Python dev would be horrified at.... Such as?
- eeperson 12y ago
  Writing tests for your build script is an interesting idea. I wonder if this would be easy to do in something like SBT where the build definition is itself an SBT project.
- pswenson 12y ago
  w/ regards to gradle using groovy.... in gradle I can easily add in variables to my dependencies, I can write conditionals (if System Prop X then include dependency Y). Basically anything you can do in code, you can do in gradle very easily. Auto-complete does work in IntelliJ 13 - at least for groovy code type stuff. Nothing for the gradle DSL (that could be implemented of course). > Java devs do many things manually that a Ruby/Python dev would be horrified at.... Jenkins config - almost every one does this by hand. Jenkins jobs weren't really even designed to be automated (ironic, eh), you have to build a full xml doc for each job rather than say apply a similar change across all jobs (add in a -D param across all jobs for example). I know this is a Jenkins specific issue, but this mentality is very common in java land. Others: have every dev manually install a database for their environment (Chef/Puppet/Ansible solve this - and what are they written in? Ruby/Python) No one would ever use java for any scripting type work, the JVM startup time is awful + the file/string libs are far less powerful/usable than ruby/python. Of course a java dev can learn one of the scripting langs, but they typically don't. this is just my experience, but note I've seen a lot of shops...
  - tieTYT 12y ago
    > I can write conditionals (if System Prop X then include dependency Y). I stand corrected. That would be extremely useful. Maven is really awkard about these things. EG: "I want to run integration tests but not unit tests". Here's how: http://stackoverflow.com/questions/6612344/prevent-unit-tests-in-maven-but-allow-integration-tests http://stackoverflow.com/questions/6612344/prevent-unit-test... Pretty lame.
    - pjmlp 12y ago
      A better solution is to use profiles.
izacus 12y ago
After doing couple of Android projects with Gradle I've felt like Maven is a godsend. It might require writing some XML to declare what your project does, but at least it WORKS and at least it does not waste my time by forcing me to write code to include pieces of projects and properly process project (e.g. including native code, Robolectric testing, renderscript and some other things). Also any compilation inside IDE's was orders of magnitude faster with Mvn than with Gradle... all in all setting up all the components with gradle took about 2-3x as much time. Mostly it seems like someone decided that because now you have code instead of XML for build configuration, they'll just skip most of the plugin design and force you to roll half of the build process on your own. Right now (at least for Android), Gradle is a colossal waste of time due to lacking features, extremely slow execution and myriad of bugs which will eat away productive time on project.
- pswenson 12y ago
  for normal dependency management you shouldn't need to write code. I've never done any android dev, so I can't comment on that. declaring a dependency is literally like this: dependencies { compile group: 'commons-collections', name: 'commons-collections', version: '3.2' testCompile group: 'junit', name: 'junit', version: '4.+' } But I am not going to be the great gradle defender :) I have many complaints..... I would have much preferred that Rake became the default build system for java. Sadly that approach never took off....
  - izacus 12y ago
    Yeah, for normal dependencies that's true. But on Android you quickly get some additional things that have to be handled by the build system: * Code generation from annotations (reflection on Android is slow, so doing code generation is way better) * Attaching native .so libraries in proper directories of APK (Maven plugin does that automatically, Gradle needed writing code for that to work) * Properly handling RenderScript backwards compatibility library (there was no Gradle support for that at all) * Testing - Robolectric is still not supported which throws a wrench into whole Jenkins/TeamCity autotest stack and needs fiddling with emulators
- 12y ago
ryanobjc 12y ago
Ah see I know you aren't an intellij user because your "XML hell" comment makes no sense. IntelliJ makes this a breeze. I'm sorry you aren't using it, that must make life really hard :-(
- pswenson 12y ago
  that's absurd. 1) I can't embed code in XML. 2) Why should I use a format that takes 5x as much space to declare something as a more usable format?
  - ternaryoperator 12y ago
    Agreed. On top of which XML has no capacity for logic, barring an incredibly contrived construct.
    - altcognito 12y ago
      What kinds of logic are you putting in your builds? That's a sign you are doing things wrong.
      - pswenson 12y ago
        hmm I wonder why this got created? http://ant-contrib.sourceforge.net/tasks/tasks/ http://ant-contrib.sourceforge.net/tasks/tasks/ I wonder if anyone said this about HTML when javascript was introduced? once a system starts getting complicated you inevitably need code. two points: * gradle builds can be completely declarative. you write code only if you need it * builds also are often used for very specific automation. in ant, you end up having to write custom ant tasks. this is fairly painful compared to just creating new classes, tasks, or scripts directly in gradle.
        ryanobjc 12y ago
        I often find that "can be declarative" means that over the long term in a big project means "isn't declarative" After all you can do functional programming in any language. Why do you need another.
nvarsj 12y ago
Actually, Maven uses XML right - as configuration, not code. This is where Ant was terrible - you ended up writing imperative code with XML statements.
smrtinsert 12y ago
Declarative builds = intelligent tooling. Would json make it better? I hate editing json too. Personally I would go with toml but wait... that would look similar to something else... Ant's real problem is that it never found a path towards next generation. Why isn't ivy included by default? I want something bigger and easier to use that isnt gradle or maven but is more along the lines of an Ant+ivy default. It should have a bootstrap script, it should understand default project directories... It should continue to be declarative, but it should have an xsd or similar descriptive format that can be used for tooling. There is a future in the ant+ivy perspective that I don't see in other build tools.

tieTYT 12y ago

> Maven also suffers from XML hell, but at least it has dependency management. I don't find it that bad. The nice thing about it is how my IDE will auto complete almost everything and it should be possible to validate it without even using an IDE, as it has a schema. I agree with your complaints about Ant. The thing I was hoping gradle would give me is the ability to write tests for my build. EG: I want to have more confidence that my maven filtering is working the way I want it to. But it sounds like gradle isn't built with that in mind. Considering that groovy is dynamically typed, if my IDE doesn't auto complete (maybe it does) I think it's possible to make the argument that Maven is the least awful of the 3. At least the maven XML has a schema. I don't need yet another way to make a mistake in my build script (ie: typing issues). > Java devs do many things manually that a Ruby/Python dev would be horrified at.... Such as?

eeperson 12y ago
Writing tests for your build script is an interesting idea. I wonder if this would be easy to do in something like SBT where the build definition is itself an SBT project.
pswenson 12y ago
w/ regards to gradle using groovy.... in gradle I can easily add in variables to my dependencies, I can write conditionals (if System Prop X then include dependency Y). Basically anything you can do in code, you can do in gradle very easily. Auto-complete does work in IntelliJ 13 - at least for groovy code type stuff. Nothing for the gradle DSL (that could be implemented of course). > Java devs do many things manually that a Ruby/Python dev would be horrified at.... Jenkins config - almost every one does this by hand. Jenkins jobs weren't really even designed to be automated (ironic, eh), you have to build a full xml doc for each job rather than say apply a similar change across all jobs (add in a -D param across all jobs for example). I know this is a Jenkins specific issue, but this mentality is very common in java land. Others: have every dev manually install a database for their environment (Chef/Puppet/Ansible solve this - and what are they written in? Ruby/Python) No one would ever use java for any scripting type work, the JVM startup time is awful + the file/string libs are far less powerful/usable than ruby/python. Of course a java dev can learn one of the scripting langs, but they typically don't. this is just my experience, but note I've seen a lot of shops...
- tieTYT 12y ago
  > I can write conditionals (if System Prop X then include dependency Y). I stand corrected. That would be extremely useful. Maven is really awkard about these things. EG: "I want to run integration tests but not unit tests". Here's how: http://stackoverflow.com/questions/6612344/prevent-unit-tests-in-maven-but-allow-integration-tests http://stackoverflow.com/questions/6612344/prevent-unit-test... Pretty lame.
  - pjmlp 12y ago
    A better solution is to use profiles.

izacus 12y ago

After doing couple of Android projects with Gradle I've felt like Maven is a godsend. It might require writing some XML to declare what your project does, but at least it WORKS and at least it does not waste my time by forcing me to write code to include pieces of projects and properly process project (e.g. including native code, Robolectric testing, renderscript and some other things). Also any compilation inside IDE's was orders of magnitude faster with Mvn than with Gradle... all in all setting up all the components with gradle took about 2-3x as much time. Mostly it seems like someone decided that because now you have code instead of XML for build configuration, they'll just skip most of the plugin design and force you to roll half of the build process on your own. Right now (at least for Android), Gradle is a colossal waste of time due to lacking features, extremely slow execution and myriad of bugs which will eat away productive time on project.

pswenson 12y ago
for normal dependency management you shouldn't need to write code. I've never done any android dev, so I can't comment on that. declaring a dependency is literally like this: dependencies { compile group: 'commons-collections', name: 'commons-collections', version: '3.2' testCompile group: 'junit', name: 'junit', version: '4.+' } But I am not going to be the great gradle defender :) I have many complaints..... I would have much preferred that Rake became the default build system for java. Sadly that approach never took off....
- izacus 12y ago
  Yeah, for normal dependencies that's true. But on Android you quickly get some additional things that have to be handled by the build system: * Code generation from annotations (reflection on Android is slow, so doing code generation is way better) * Attaching native .so libraries in proper directories of APK (Maven plugin does that automatically, Gradle needed writing code for that to work) * Properly handling RenderScript backwards compatibility library (there was no Gradle support for that at all) * Testing - Robolectric is still not supported which throws a wrench into whole Jenkins/TeamCity autotest stack and needs fiddling with emulators
12y ago

ryanobjc 12y ago

Ah see I know you aren't an intellij user because your "XML hell" comment makes no sense. IntelliJ makes this a breeze. I'm sorry you aren't using it, that must make life really hard :-(

pswenson 12y ago
that's absurd. 1) I can't embed code in XML. 2) Why should I use a format that takes 5x as much space to declare something as a more usable format?
- ternaryoperator 12y ago
  Agreed. On top of which XML has no capacity for logic, barring an incredibly contrived construct.
  - altcognito 12y ago
    What kinds of logic are you putting in your builds? That's a sign you are doing things wrong.
    - pswenson 12y ago
      hmm I wonder why this got created? http://ant-contrib.sourceforge.net/tasks/tasks/ http://ant-contrib.sourceforge.net/tasks/tasks/ I wonder if anyone said this about HTML when javascript was introduced? once a system starts getting complicated you inevitably need code. two points: * gradle builds can be completely declarative. you write code only if you need it * builds also are often used for very specific automation. in ant, you end up having to write custom ant tasks. this is fairly painful compared to just creating new classes, tasks, or scripts directly in gradle.
      - ryanobjc 12y ago
        I often find that "can be declarative" means that over the long term in a big project means "isn't declarative" After all you can do functional programming in any language. Why do you need another.

nvarsj 12y ago

Actually, Maven uses XML right - as configuration, not code. This is where Ant was terrible - you ended up writing imperative code with XML statements.

smrtinsert 12y ago

Declarative builds = intelligent tooling. Would json make it better? I hate editing json too. Personally I would go with toml but wait... that would look similar to something else... Ant's real problem is that it never found a path towards next generation. Why isn't ivy included by default? I want something bigger and easier to use that isnt gradle or maven but is more along the lines of an Ant+ivy default. It should have a bootstrap script, it should understand default project directories... It should continue to be declarative, but it should have an xsd or similar descriptive format that can be used for tooling. There is a future in the ant+ivy perspective that I don't see in other build tools.