Category Archives: maven

Something Java should never do

I’ve been working on a pull request on Spring HATEOAS for six weeks. That’s right, six weeks. It was a community contribution, and there’s a lot to sift through. Yesterday morning, I was slated to conduct the first review with the project lead. But that wasn’t going to happen, because Java decided to do something Java should never do.

Maven wouldn’t build my project while IntelliJ IDEA would.

I was alerted to this issue Thursday morning when I created a “run all profiles” script and it wouldn’t work. Huh? Every time I’ve pushed an updated commit to Travis CI, it builds perfectly. That’s right, a CI server, running Maven, built my branch with ease. But my Mac would not.

This made no sense. This is something Java should never do! Java doesn’t work on Linux but fail on a Mac. It must be my machine, right? So I log onto my wife’s MacBook Air, update Java to the latest version, grab the source, and fire off Maven. BOOM! It breaks just the same.

So…here comes the online review with Ollie. I pronounce my inability to build the system. The man with twenty years professional experience, who has written four tech books and one tech video, who has been fighting this for twenty four hours, pleads with his manager for clues. Ollie grabs the branch, tries to build, and SPLAT. It doesn’t work. He goes through the same questions I do, and finds no answers.

We jump to our OTHER CI server, Bamboo, and he commands it to build my branch. It works. Perfectly.

Score so far: Three Macs – 0  Two Linux CI servers – 2

“Ollie, this is something Java should never do!” I scream into my Google Hangout. (Okay, maybe I didn’t scream.)

He nods along. The review is busted. We both flip to our daily standup Hangout, and Ollie’s first words are, “Greg, I know what you did.” Heh.

We wrap that meeting up, and I proceed to dig through every Stackoverflow article I can find on Lombok, maven-compiler-plugin, and Java 6. Talk about a nebulous combination. WIth enough evidence that this is Lombok’s fault, I open a ticket.

Fun day, given it’s my son’s last day of school for the year. I’m irritated at having to stop work to fetch him. My brain keeps churning the whole time. The second I get home, I have him go play. Anything to get back to my keyboard and keep trying options. I flip through a myriad of options for maven-compiler-plugin: memory, forked JDK, use Java 8, hand configure annotation processors. Nothing works.

My three-year-old is trying to climb up on me, and I push him to the side. “I must find the answer!” Time to pick up our 7-year-old arrives, and I dash off. After getting home, she is asking me to write LOGO code. “No sweetheart, I need to try something first.” I usually stop ANYTHING to help her, but I was too obsessed with this issue.

At this point, I start to De-lombok the code. Maybe if I can flip Lombok off. I get 90% of the code converted, and IT STILL WON’T BUILD! What could this possibly be? Every debug/verbose flag I activate still shows me nothing about what is actually breaking. Just some missing symbols followed a completely corrupted class.

Then I get a strange idea. A curious insight. What if the first class that Maven claims about, a nested static class, was made top level? I command IntelliJ to perform this refactoring. Poof, the error message changes. So I make the next nested static class in the list of errors top level as well.

BANG! Reading “[INFO] BUILD SUCCESS” makes my jaw drop.

I cancel all my changes, and build again. Same failure. I then strategically pick one nest static class, and move it. Everything suddenly works. What the…? This is something Java should never do.

Looking at the Jackson2HalModule (the predecessor to my work on Jackson2HalFormsModule), I count the number of nested static classes and compare to this one. The HAL parser has eight or nine, the new work has over twelve. Somehow, this enclosing class has TOO MANY NESTED STATIC CLASSES!

Not wanting to move everything into public classes, I rig up HalFormsSerializers and HalFormsDeserializers, and split up the nested static classes into these two “namespaces”. Everything is humming. This change is mind boggling. Because this is something Java should never do.

So what is happening? Still not sure, but it implies that Lombok’s annotation processor must scan every class looking for its annotations. If the class is too deep, the scanner breaks and doesn’t recover, hence causing any nested classes further on to fail. And somehow, this state is contingent on the platform, because it works jim dandy on Linux while failing on the Mac.

I copy all these details into the Lombok ticket I opened. I hope I shined a light on an issue perhaps the committers can pinpoint and fix. But for now, my PR is buffed up and reviewable again. And as I go to bed, I can finally sleep in peace, having slain another dragon in the realm of open source hacking.


Gradle or Maven? I really don’t care

The project I’m working on, Spring Data REST, recently rolled out a big update: they changed the build system from gradle to maven!

This kind of shocked me at first. I’ve been hearing that gradle is hip and cool and maven is old and stagnant. All hail gradle!

And yet, in just a few hours, I realized that I really didn’t care. I didn’t care because both gradle and maven are GREAT build tools. That automate the entire process. Since 99% of my time spent on a given project is in the source code and support scripts and NOT the build process, I don’t really care a lot about what build tool is in use.

I understand people run into issues with maven. If you try to deviate too much from the convention you will pay for it dearly. Guess what; it’s not that hard to follow the convention. It’s not a bad price to pay for being able to jump to other projects and see the same layout. It’s also handy that IntelliJ IDEA can easily suck in a multi-module, maven-based project without batting an eyelash.

What about gradle? It’s pretty neat as well. I sure enjoy updating the build system when needed without having to bear all the XML cognitive overload. Gradle’s groovy-based system is simpler to read. I appreciate that IntelliJ IDEA can also crack open a gradle-based app just as well.

But then again, it can run away. I’ve seen REALLY complex build systems (like the Spring Framework). It becomes an art to discern all the stuff involved to build that hunk of software. Why? Because Spring has a lot of stuff going on! No build system can make it super simple.

Pros and cons for each?

  • Gradle it easier to read. No XML overload. It’s easy to use, declarative, and comes with gobs of plugins. I have even had people tell me that crafting your own plugin is pretty easy. But it doesn’t have the concept of parent projects that can provide inheritable version numbers
  • Maven is widely adopted. Even when we wanted to primarily use gradle for Spring’s Getting Started Guides, we decided that maven support could not be ignored. Maven has more than one way to inherit a set of dependencies and properties. This feature is REALLY useful. Spring Boot leverages it widely, effectively declaring a stack of dependencies it uses.

Bottom line: either one of these are better than some ivy+ant solution. I have worked with ant in the past. It is so customizable, so detail oriented, so extensible, that you can ONLY interact with it at the low level. I don’t imagine IntelliJ IDEA being able to suck in an ant project and immediately fetch all it’s dependencies.

You are dragged down to that horrendous level of detail every time you want to dig into an ant-based build. Most of the time, when I interact with the build system, it’s because I need to roll some versions and upgrade things. Maybe add a new module. That’s easy.

In the end, trading in such detailed complexity has a huge productivity payoff. I have to use both because of the proliferation of projects, hence, it’s not a steep job for me to switch gears.

Putting your money where your mouth is

I like maven. There, I said it. Now where is my flame suit?

Last night at the Nashville Java User Group meeting, Kerry gave a good introductory presentation on maven. He talked about the pros and cons, and showed some things like phases, profiles, and parent/child projects. For those who had little to no experience with maven, it was a good introduction. Hopefully they will read more.

I jested afterwards that he should write a blog entry to generate traffic for his web site, because a discussion about maven is never luke warm. People come out either strongly for it or against it. I expressed this at last night’s meeting. Well, sitting here this morning and checking twitter, etc., I realized that I would be a bit of hypocrite if I wasn’t willing to put my money where my mouth was and write my own blog entry.

So here we go. I like maven for a handful of reasons:

  • consistent format of project layout
  • transitive dependency management
  • more plugins than I can imagine
  • declarative definition that supports convention over configuration
  • maven’s one-artifact-per-project promotes a better breakout of modules
Does maven have issues? Yes. What build system doesn’t?
Is it state-of-the-art? No. The XML can be wearying.
These seem to be the two key things that cause people to discard it and seek something else. I have seen this first hand. Instead of using maven, someone typically tries to replicate maven’s intentions using other technologies. If you are on a team where someone has built their own build system there is another dependency that can start to get in your way and come incredibly annoying: that person. Any issues with that build system require support of that person because there is not likely to be any documentation. I didn’t like this aspect, and when that person worked in a different time zone than me or was on vacation, it became detrimental to productivity on occasion.
So what about things like gradle? To tell you the truth, I am kind of excited about new technologies like gradle and sbt. They look very appealing, and I really like the idea of using groovy or scala instead of XML. XML is a strain to read, though for some reason, I find myself reading pom.xml files instead of using my IDE’s editor.
I guess being a command line junky, I prefer to work with the real file rather than a massaged presentation. Probably makes me sound like a dedicated emacs user. While I use vi a lot, I also edit a lot of code inside my IDE. Nothing beats the ability to highlight 200 lines inside my IDE and hit the comment key combo. I use both on equal footing, and it makes me feel like I’m versatile. But…I digress.
Back to the topic at hand: what about new build technologies like gradle? I think a critical feature of tools like gradle would be integration with maven. I understand this is in the core of it, so hopefully gradle will expand and become more mainstream. But right now, I haven’t adopted it.
Go and figure out what meets your needs. But take into consideration what happens when you hire more people. Will you be able to point them at standard documentation, or will you have to be on call to answer questions about your build system? It’s up to you. Just be aware that something like 85% of all java projects use maven. (Okay, I don’t remember the actual number, but according to a survey conducted by the Eclipse foundation, it is a HUGE majority like that). It’s one less impedance mismatch to deal with. Be sure to factor that into your TCO (total cost of ownership).
Whatever you choose, happy building!