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.