Maven and IVY Dependency Management IV

What is Maven

In this post I am not explaining how Maven is used, or the artifacts within Maven. These are very well explained in the existing documentation. In this post I will be sharing the experience of using Maven heavily over the past 2 years and comparing it to other tools that are out in the marketplace. This post is valuable to Software developers and Techical Management. It is assumed that the individual reading this post has used Maven previously and knows terminology such as "POM File" and "build."

Maven can be considered to fulfill any or all of these types of products:

• Project Management Tool

  Maven integrates with a few good project management tools, but one of it's first uses was the ability to generate a set of web pages defining the project. This was very useful when it was used by individuals on Open Source projects because at the time there was no open-source project management tools around that would build these pages by default.

  Personally when I first reviewed the first release of Maven I found that it made the use of Maven a tad complex and decided not to use this feature. As it turns out this feature was eclipsed by many of the products that people use today like Blogs and Wikis. The really nice thing about Maven in this area is that it does automatically produce a very nice product page without work beyond putting in the name and purpose of the project.

  Project management is key when developing large projects that have many components and many individuals working on it. There are a few project management tools that are available for no cost. Usually you can find these products inside of others such as Trac or Alfresco (which has a content type for programmers), Google Code, and Windows live services. These are all, in my opinion among others a better and more complete alternative to using Maven 2 alone for project management. I have not attempted this but I have heard of teams using configuration management tools to generate the POM files

• Build tool for software development.

  This is where Maven really shines, and also has some room for improvement.

  Maven Shines...

  • Maven provides "structure" for Java programmers.

    It gives developers and development groups a standard directory structure that every POM file will understand. This is very powerful because when you go from one Java project to another it can have a completely different set of directory structures and can add a layer of complexity. If you violate these rules, the build system will not work effectively by default from Maven and the programmers will have to understand the details of the build, which should not be a part of their world.

  • Maven has been designed to use the "Convention over Configuration" principle.

    This implies that by convention Maven assumes that your projects are setup a certain way and that as software developers add different "Conventions" they will not violate previous ones that have been used. This creates a standard build system that out of the box will build a project from scratch and place it into the Maven repository to be used by other projects.

  • Maven is built around the concept of component development and usage.

    Most build systems that are built in Ant rarely allow for the complexity of building 20-30 projects with hundreds of dependencies. Maven allows for this and definitely has the capability to resolve these issues. If you haven't spent many hours trying to figure out why your web application says "cant find method xxxx" then count yourself lucky. This is typically caused when you have two different versions of the same jar file in your Java classpath. This can get ugly when you have 20-30 jar files that you have added to your Java classpath for a project. These issues are not completely resolved by using Maven, but generally they are reduced by the way that Maven tells you that there is a conflict and then gives you the tools to solve the conflict.

  • Maven has the ability to look inside of a products' dependencies and if they conflict with another jar file that is already loaded.

    It shows up as conflict within Maven (when you run mvn-install, build, or package). This is important because this solves one of the major "time eaters" in a Java developers work day. These issues are pertinent to many Java architects and senior developers where their main goal is to enable other individuals to work without having to understand or have to think about the details of how the larger project is built.

  Maven, of course is not the holy grail when it comes to build systems and has it's problems. These problems are not issues with the design or architecture of Maven, but with the ecosystem that developed around this project:

  • Repository issues

    There are too many Maven repositories with the same products, i.e. there are too many places that have differing versions of the same products. It doesn't happen very often but I have found different public repositories that have different versions of the same open source projects. It can be very confusing to find the "latest" out on the public repositories if you don't know the project well.

    Maven repositories are everywhere, and there is one for every product.  It seems to me over the past year that the number of repositories with projects have been exploding.  In some ways that is a good thing, but when you are trying to find a product that you expect to be out on a common repository, and it isn't there it can be very frustrating.  As the Internet is not run by one person or one organization these decisions can't be made anywhere but the community of users.  There must be a process by which current versions of projects and new projects are placed onto a common repository.  As this is not my area of expertise I will say that it's confusing for the experienced user of Maven and I know people who have stopped using Maven for precisely this reason.

  • Confusing documentation

    Although the documentation is great for Maven in comparison to other open source projects, it still doesn't really make it easy to use Maven.  The documentation for the most part is written from a completely Java technical perspective, which is fine but now that Maven is maturing and is more heavily used in corporate development better documentation will ease it's integration.   Although it is a better product than most of the build managers out there commercial or not, it loses some of it's punch when higher level individuals attempt to read the documentation from the website.

Next Time....

• Configuration Management Tool
• Interoperability tool for software development