So you discovered Maven, but you haven’t got a clue how to convince your company to introduce it?
Maven might sound like another nerdy thing a developer just wants to try. Your boss wants to see numbers, proven solutions, costs, benefits, etc. It’s true, Maven does have a (big) learning curve, but that’s more because Maven offers so much functionality. It’s much more than a compiler wrapper, but that is where it starts.
So here are some magic words which should get everyone’s interest: more stable releases and less to no regression, real modular-based development.
Use Maven beside your current builder
While everybody is working on a certain project, you’re free to introduce maven no matter the structure of the project. The only thing you have to do is add one file: the pom.xml. The other developers might notice this file but it won’t bother their project.
In other words: the risk is zero!
This is of course very important. While one person is focused on the Maven project configuration, all others can continue their development work as they’re used to. If the original builder was based on an ANT-script, Maven should be able to cover it all. If you use some special ANT-functionalities, there’s an ant-plugin available for maven to run these scripts.
By configuring your projects pomfiles it’s quite easy to proof that Maven can do at least what the original builder could do. Once the project is fully mavenized migration is very simple, because it’s actually already done. The most important thing to do now is to decide that from now on Maven is the leading builder-mechanism. If it doesn’t build with Maven anymore, somebody broke the code. Also: dependencies will be managed by Maven.
Introduce project team members in seconds
In the ol’ days helping another project team would take a lot of time. If you’re using Eclipse, you have to create a new workspace, checkout the projects (including all jars like that commons-lang for the gazillions time), setting all the paths, adding the libraries to the project, setting variables, setting jdk-version, etc, etc. and than: fingers crossed.
With Maven all this kind of information is stored inside the pom. You can run it from the command line, or with a little help from the right IDE-plugin (you should try m2eclipse for example). Just run Maven and see you’re project getting build. Also: because of its predefined structure every developer should be able to read the pom-file and understand every part of the java-project. You should try that with an Ant-file…
Don’t release with failing tests
In the ol’ days if you wanted to check some functionality of a class, you would write junit-tests, run them until they’re all green and …. Well, there’s actually no ‘and’, because most tests are used only once. That’s a shame, because this piece of code will help you stabilize your code. With Maven it’s not possible to package without all tests succeeding. (Don’t tell anyone about the ‘skip’-options.) This way it should be very hard to get regression. Also, fixing bugs will follow a standard process: reproduce the bug, write the test (test will fail) and fix the bug (test will succeed). Tests won’t be written anymore for single usage, it may become the most reused code.
Check out smaller projects
In the ol’ days every java-project was stored completely with their depending jars. If you had multiple projects depending on shared jars, you would add a special directory with these jars. From the java-project you had to point to this folder. Often these jars were checked in into some Source Control Management (SCM) System like cvs or subversion, sometimes you had to link to a shared network-folder. One way or another: you always had to modify your project manually to get it buildable.
Personally I believe jars shouldn’t be stored together with the sources of the project. It should only contain the project-sources, not any third party stuff like jars.
With Maven it’s possible to keep your SCM as clean as possible. When using jars as dependencies, Maven will refer to a (local) repository. There is no reason to download a jar by hand and add it to your project in some way. Also: upgrading jars has become much easier. Just change the version of the dependency in the pom and Maven will do the rest. Another interesting thing: Maven can help you support real modular jars. Quite often managers talk about modules, but in the end they’re just part of that one huge project because it’s hard to keep control over separated (versioned) jars. With Maven such modular jar is just another dependency. Upgrading is nothing more than changing the version inside the pom. But to break up one huge project into a core and several modules requires some migration-steps. Every project requires its own strategy, so that can be stuff for another blog.
Say goodbye to the jar-hell and welcome updates
In the ol’ days adding or updating a jar could very well result in new errors because of it’s own missing dependencies. Hopefully there’s some documentation available which lists it’s dependencies, but most of the time you would have to search every corner of the internet collecting those missing jars. So most of the time projects stick to a certain version of a jar until the end of days.
With Maven your project contains a pom with all its depending jar. But such jar (if mavenized) also contains a pom with al its dependencies. This way Maven is able to collect all direct and indirect dependecies of your project.
Experience the advantage of a Company Repository
One important product, related to Maven is a repository manager. A maven repository itself is nothing more than a structured directory tree. But with some help of a repository manager you will have extra power to control your projects. (Right now the best choice would probably be nexus, since it has been co-written by some maven-core developers)
Reuse company code
Almost every developer has its own brilliant piece of code he wants to use on all his projects. In the ol’ days it was quite hard to use the same code in several projects without copy-pasting. And we all know what that means: bug fixes won’t be fixed on all copies, new features and improvements won’t be shared.
A repository manager has a space to collect this type of company-code. By deploying/uploading such jars to the repository manager all other projects can make use of the same codebase.
Increase download speed, decrease load
One of the functions of the repository manager is proxying the maven central repository (and if required other maven repositories). If all developers point their Maven to the repository manager, all jars have to be downloaded only once (from the other side of the world). From that moment the jar is available between your company walls and developers can get it from there. Now you will also have some sort of backup for your jars, so once used jars won’t disappear anymore.
Experience the advantage of a Continuous Integration Server
A continuous integration server is a neutral building server. A project is only valid if it can be built on this machine. So the top-10 developer-quote “But it works on my machine…” cannot be longer accepted. It would be encouraged to release your projects from this machine. Don’t claim time from a developer’s machine and also don’t trust those machines (with their special settings and utilities).
Continuous Integration servers have the ability to run builds every now and than. This can be based on time (every night) or on check in. This way developers will be very soon triggered if they broke a build. They can immediately fix their features instead of discovering the bugs during tests (or production).
All this together (and there are probably more convincing reasons) could help you introducing Maven. If your audience it technical enough you could also mention that you don’t have to write or maintaine build-scripts.
Robert Scholte's Blog 