4 ms·
For starters, you can see Groovy as "Java without semicolons". I went from Maven to Gradle and never looked back. It's superior in most ways. The tooling could
by emsy 13y ago
For starters, you can see Groovy as "Java without semicolons". I went from Maven to Gradle and never looked back. It's superior in most ways. The tooling could be better though.
- lmm 13y ago> For starters, you can see Groovy as "Java without semicolons" Not if you have to read other people's code, or understand examples you find on the internet. > I went from Maven to Gradle and never looked back. It's superior in most ways. What's it better at? I want my build tool to be simple; maven compiles my source and does my releases, and the main thing I have to configure is just a list of dependencies (in an admittedly verbose format). I'm actually a scala programmer, but I use maven rather than SBT because it seems to me that having lots of logic in the build system could only lead to bad things. So what are the things you see it helping with?
- dminor 13y agoMaven is simple as long as your build is simple. As soon as you need to do something custom, it's a pain. Gradle is less painful.
- emsy 13y agoSee my reply to vorg regarding Groovy. As a developer the argument "I don't want to learn something new" is invalid. Gradle offers the declarative nature of Maven without pushing it down your throat. You don't have to write a plugin for something that can be expressed in 3 lines of Groovy (but you can, if you want to!). Instead of adapting your build to Gradle, Gradle adapts to your needs. That's often a point of criticism from Maven users, because every Gradle build looks different. But that's the point: Everyones needs are different. Of course that only applies if your build is beyond the standard compile/test/release configuration. A simple configuration looks pretty much like a Maven POM (minus the tag soup).
- vorg 13y ago> you can see Groovy as "Java without semicolons" Only a very small subset of Groovy is used by the typical Gradle build script, the very subset of Groovy that's least like Java. What part of this build script from the linked article bears any resemblance to Java?... apply plugin: 'java' apply plugin: 'application' sourceCompatibility = '1.8' mainClassName = 'jmodern.Main' repositories { mavenCentral() } dependencies { compile 'com.google.guava:guava:17.0' testCompile 'junit:junit:4.11' // A dependency for a test framework. } run { systemProperty 'jmodern.name', 'Jack' } javadoc.options { docletpath = configurations.markdownDoclet.files.asType(List) // gradle should relly make this simpler doclet = "ch.raffael.doclets.pegdown.PegdownDoclet" addStringOption("parse-timeout", "10") } run { jvmArgs "-javaagent:${configurations.quasar.iterator().next()}" // gradle should make this simpler, too }
- emsy 13y agoI understood the post I replied to as if the author wanted to configure something custom and thus needs to write code. I didn't assume that the original argument was supposed to address the configuration of a standard build. Because you'll always have to learn a new syntax for the tool. Use Make-> Learn make syntax. Use Maven-> Learn POM syntax. Use Gradle -> learn the DSL syntax. Want to extend Gradle -> learn Groovy, a "superset" of Java.
- zak_mc_kracken 13y ago> you can see Groovy as "Java without semicolons I see it as "Java without types", myself. I'm aware that Groovy now supports optional typing but if I'm going this path, I prefer to switch to Kotlin, which I describe as "Java with everything that's bad removed".
- lmm 13y agoIf that's what you want wouldn't Ceylon be a better choice? If you're still using the Java standard library you still have the billion dollar mistake (null) everywhere.