Gradle vs Maven false advertising and industrial sabotage?

It looks like my timing was perfect to uncover how dirty the IT industry really is. If you open your favorite search engine and search for “gradle vs maven” you will find some well written propaganda telling you how much better Gradle is than Maven. Even freenode’s ##java channel is filled with developers who tout the “Greatness” of Gradle. In the words of Public Enemy, “Don’t believe the hype!”.

Let’s get right to the fact’s shall we? Most review’s are opinions anyhow, what I’m going to present are facts.  I started my adventure into Gradle by looking for the best Eclipse IDE plugin for Gradle. What I found first was a plugin named “Gradle Integration For Eclipse” but when I tried to find it in the official repository linked with my IDE it was nowhere to be found.  Instead there was another plugin for Gradle which wouldn’t install.  I did a quick search and found what appears to be a clear case of Industrial Sabotage. According to a post on StackOverflow the plugin was discontinued (By Who?).  Gradle users are instead “expected” to switch to IntelliJ which has Gradle support from Google. Sure, this is absurd, but this is also Open-Source. If the only way to use Gradle is with IntelliJ than I’d definitely boycott the technology. Even with a solution I’m tempted to boycott IntelliJ. Sure I have it installed, but I never use it. IntelliJ applications tend to be highly dependent on the IDE for development which is a deal-breaker for me.  Applications should NEVER be dependent on the editor used to create them.  Sure, it happens often, but it shouldn’t. Developers SHOULD be free to use any IDE of their choice. Locking developers into a single IDE opens up too much opportunity for Industrial Sabotage. To conclude part #1 of my miss-adventure, I discovered the eclipse Buildship project which provides integration with Eclipse.

I’m going to keep miss-adventure part #2 short. I created my first Gradle test project. It went smoothly enough though I was immediately disenchanted when realizing that it’s coded in Groovy, a technology that is largely deprecated by the Scala language. After starting my first Gradle test project I decided to convert it into a real project. In Eclipse this is usually a fundamentally easy task and simply requires renaming your project. I said USUALLY, and true-to-form with Gradle inferior technologies, after renaming the project it no longer functioned (See: Bug Report).  At this point the illusion of Gradle being superior was fully destroyed. It became clear that Grade technology is immature. Not only that, but as such a low-quality technology that claims to make it “easy” to build applications, it is attracting under-qualified developers in masses which is probably why the support technologies aren’t fully functional.

For the final part of my miss-adventure, it turns out that Gradle doesn’t currently have functional OSGI support. Anyone familiar with OSGI can clearly identify this issue as improbable, but it is a fact (See Example Bug Report). This isn’t actually a single bug, but a number of related bugs. There are work arounds for some, but not all, of the bugs so it won’t produce a bundle. Nearly all of the core OSGI technologies are open source and converting a Jar into a Bundle can be as easy as adding a few manifest headers. There is also a standard tool, bnd, that is open source and generates the manifest headers for you, mostly automatically.  I’m not entirely sure how the Gradle ‘osgi’ plugin developer screwed it up, it literally only took me 1 hour to build a script that automatically converts maven dependencies into OSGI Bundles, using pure Java and XML based dependency descriptions.

Now for my review of Gradle.  Sure it’s broken but take a step back to look at what Gradle intends to provide. It intends to provide a code driven build system. As someone with a small amount of AI experience the idea literally makes my head hurt.  Why would anyone intentionally try move technology backwards?  It has been known for the past 20+ years that data driven architectures are simply “smarter”. In one way or another EVERY build system I’ve ever used (Make, Autotools, Maven, Ant, Leiningen) is based on a data driven architecture.  Sure, there is code involved. At the core all source code is effectively structured data, but some data structures are simpler to parse than others. Groovy is the DSL of Gradle and it isn’t a simple parse compared to XML or Lisp data structures. Even “ancient” line based tools like Make and Autotools are relatively easy to parse, but provide a much less direct representation of the structure of the machine state.  In my opinion Gradle is a technology born of ignorance. I suspect the average high-school level programmers could make a better build system than Gradle with pure Java. With the sheer over-popularity of Javascript I suspect Gradle will soon be replaced by Javascript.  If your NOT looking for an intelligent data-driven architecture, the language you develop it in doesn’t matter much. With Javascript being the programming language of choice for non-programmers it doesn’t take superpowers to predict that the average Gradle advocate would jump at an equivalent system in Javascript. For now I’ll keep using Maven and Leiningen, they both work, and they’re both data-driven!