Getting to know Maven

 I've actually been working with Maven for awhile now.  Like many tools, once I was able to get it to do what I needed, I didn't plow ahead to learn how some things were supposed to be done.  Maven is nice, perhaps even essential to at the very least just building a Java project, the larger the project, the more essential.  It is, however, a beast.  There is so much to it and with the growing number of plugins, it will be difficult at best to keep one’s brain wrapped around all it can do.

I was recently asked to clean up some web services and be prepared to share the source code with some of our working partners.  While my builds work, the deliverables are bloated, probably storing all kinds of 3rd party jars that are not required for production releases.  So it’s time to start understanding Maven better so that at the very least I don’t break something cleaning things up and at the best, make the project more conformant with Maven standards.

Here’s a little peek at my ignorance at work in the development process.

1. when building anytime, project jars are installed to the local Maven repository
2. before each build, I run a shell script to manually remove my project package out of the local repository (~/.m2/repository)

There are some pros/cons to mention with this approach:

Pros

• builds can be faster since one can pick and choose which modules get built
• the process is very transparent; there’s not much guessing of what’s going on

Cons

• it’s not very Maven-like; the further away from following the standard approaches, the more likely other developers will simply chuck your code and write it again
• you have to remember all the relationships between sub-modules; if you’re just coming on to the project, that’s not trivial
• you might forget to rebuild a sub-module after that tiny change you made

The advantages of doing things the Maven way are worth following

• Maven worries about determining when to build sub-modules. Even though it may mean longer build times, you will have greater confidence that things get built right the first time.
• you don’t have to litter your project with shell scripts; Maven commands are all you need
• you are much better positioned to take advantage of plugins instead of figuring out how you may need to make changes to all those convenient shell scripts
• more available support; less documentation you have to write

The Journey Begins

One of the first things I recognize is that installing my project jars is not a good idea.  Coming up with some other way to make sub-modules available to each other is not a good idea; Maven has already accomplished that task for 80% of all cases.

Another thing I recognize is that I have not managed my dependencies well enough.  I’ve only recently become aware of <dependencyManagement>.  I will organize my dependencies better such that my deliverables aren’t gargantuan in proportion.

To make sure that I use the same versions of dependencies and plugins, I will make use of <dependencyManagement> and <pluginManagement> in the parent pom.xml.

I will scan for places where I succumbed to abusing the maven-install plugin and determine if it’s use is really merited.

These items are just the beginning to a journey I think will really help me better understand Maven.  In a way it reminds me of how finishing my home’s basement also providing me with an education of home construction and maintenance, no longer fearing to punch through a wall to reinforce a towel rack.

Let's get started!