Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Withering Maven Rant from Hibernate Guy

DZone's Guide to

Withering Maven Rant from Hibernate Guy

· Java Zone
Free Resource

Download Microservices for Java Developers: A hands-on introduction to frameworks and containers. Brought to you in partnership with Red Hat.

Having succumbed quite often to the need to rant, it was with great pleasure that I plowed through this evisceration of maven as a build tool. For those of you who don't salivate at the prospect of a long slog through a field of nattering nabobs of negativism, let me break it down for you. The real crux of this thing is that, after 8 years, any effort to see a way through the Maven jungle to what we call a release is a. sure to be filled with torture and b. impossible. I am sure I ranted about this some time ago, and this was synchronicity at its finest that I happened across this right after moving all my projects from one nexus install to another because one of the nauseating takeaways was we had no projects that were doing disciplined, layered versioning as part of an automated release.

Let‘s pause for a second to consider how utterly ridiculous this is. A build tool that cannot create releases in an orderly fashion is kind of like a phone that can‘t place a call. One of the funniest parts of this rant is the fact that once the author identifies an element as utterly dead, he adds that the Czar of maven agrees and has announced his intention to replace it with ‘something new‘ (of course there is no timeframe for this, you see, timeframes are for nazis that live in walled gardens).

I found this post because I wanted to look at Gradle again, and that was because I came across a conversation with Colin of Spring fame some time ago where he was declaring its usefulness.

Having just skimmed the surface again of Gradle, here are a few random comments:

  • Love the idea of a DSL, the bland assertion that Groovy was the right choice because Ruby and Python are better languages than Java is kind of silly. The initial hello world examples are not at all convincing from this perspective. Looks like more of the same: my languages‘ highest goals should be to give me less finger pain from typing, and to make me feel like I am on the cutting edge of coding fashion. I like the O-C conceit: a language‘s highest yearning should be to readability. I think I could make a build DSL in Java that would be a lot more compelling than this in a few days. Sound arrogant? Imagine chaining calls to assemble artifacts or trigger actions, with simple inline rules in anonymous classes. Simple and clean.
  • The documentation looks decent. But there‘s a new O‘Reilly book that has gotten lambasted on Amazon. Then you see it‘s the first in a proposed 3 volume series. A build system so simple it‘s going to take 3 books and 2+ years to describe all of its beauty (and some hundred dollars or so).

Look at the included source code. If this syntax makes you so excited you want to get out your old matchboxes, you are probably a good candidate for liking Groovy. The infantile fascination with banishing iteration loops is just boring to me, and overall, the code is not more readable than a Java-based DSL would be, period (imho). Furthermore, things like ‘println‘ are totally whacked: if you are going to sell yourself as the vanguard, what on earth would make you reach into one of the ugliest parts of C‘s past, that C++ undid with streams?

On the plus side, even a cursory look at Gradle makes you realize that Maven‘s central conceit: to add a model to what was before a model less wild west of silly string (ant), didn‘t go far enough. Why? Because it really only models the dependency graph, and while it has ambitions to incorporate the build, even the most basic things are left to bolt ons (e.g. surefire). One of the things that Ebersole does not address but would be super high on my list is getting better control over the running of tests. We have a number of projects that have both JUnit and TestNG tests in them, and setting that up to run is a nightmare, then if I want to control what gets run to produce what artifacts, I am left, as SE says, portioning out a strategy as a tool‘s grant or remainder. I would so like to be able to say ‘run these tests when producing a dev artifact, these for production‘ and also be able to say ‘the tests for this artifact need only be run if x happens.‘

The biggest thing is the releases. If you got a few smart people in a room who have worked on large projects, and did some visioning on what a release lifecycle management tool should do, face the facts: it‘s 2000 light years from where Maven is.

This was my favorite line from the rant, in part because it overlays one of the things I‘ve been kind of obsessed with lately: the role of the conceptual in technology. “The entire conceptualization of the build process is much cleaner in Gradle imho.” One of the reasons it was hard to have a lot of sympathy for the car companies (for me personally) is they got more post subsistence dollars than anyone in the 50 years after world war II and delivered so little in the way of real progress. While 50K people a year were dying it took them something like 3 decades to put an airbag in a car. Sadly, we in technology imagine ourselves as promethean barn burners, but the reality is the vast majority is probably no better at keeping a pace of their problem space.

From http://www.jroller.com/robwilliams/entry/withering_maven_rant_from_hibernate

Download Building Reactive Microservices in Java: Asynchronous and Event-Based Application Design. Brought to you in partnership with Red Hat

Topics:

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}