Starting a new Maven project, what landmines to avoid?

Question

I'm starting a new project. I intend to use Maven for the first time. From reading previous threads, the folks who like Maven have me convinced... but the folks who hate Maven seem to have stepped on landmines, and I'd love to have more details.

It seems like I'll be bound into following Maven's conventions. Is that an understatement? Is there something else?

*This will be a medium-size, medium complexity project; my ballpark would be 10k lines of code, growing to no more than 100k in it's lifetime. (I'd consider big to be >500k, and small to be <10k, FWIW).*

Yes, I'm using Maven. If the pitfall is "Maven", without any other details, you're wasting bandwidth on the reply.

Answer 1

Indeed, following Maven philosophy and thus its conventions is a good idea as not following them will make things more complex.

But, because it seems hard to summarize the philosophy in one answer, because Maven has a bit of learning curve, and because Maven documentation is not always as good as it should be (this is maybe the biggest land mine), my advice would be actually to grab a book (or two) and to do things as in the book. If you don't know which one to pick, have a look at this page. In my opinion, Maven: The Definitive Guide and Better Builds with Maven are definitely good readings and are available on-line. But the later one Apache Maven 2: Effective Implementation co-authored by Brett Porter must be a good one too, I just didn't read it.

When you'll get started, don't hesitate to ask for advices, guidance, pointers on specific topics to take the right path. The maven user list is a good place for this. Asking questions here on StackOverflow is another option :) For example, how to organize a multi-module build might be one of the first topic. But without more details, it's impossible to answer right now.

Answer 2

I would definitely recommend setting up a nexus repository at your location. This is free and will help integrate non maven repository jars, and cache them locally to improve performance of setting up a new environment.

Answer 3

My prior answer on setting up a group wide repos might have some helpful advice. As well as this on splitting up projects.

Answer 4

Don't use fancy features you don't really need, such as:

• Multimodules
• Parent poms

Try to stay as plain as possible for as long as possible. Play through the release cycle very early, e.g. by performing releases of 0.0.1 versions. Get it automated.

If you are using a complex set up (e.g. Eclipse + m2eclipse + WTP + aspects), be prepared for some glitches and know where each tool is storing it settings, temp files etc, so you can manually clean them if necessary. Much time can be lost if you're thinking "maven does it all" just to find out that a Snapshot dependency has not been updated due to caching or alike.

Answer 5

In the term of 'Maven' we think of Maven core and the bunch of plugins, which are developed by Maven team or other people. Things that aren't perfect in Maven world are:

• difficult to understand scopes of dependencies, which leads to common mistakes in users poms and third party vendors poms, which causes a big mess if it is common used library,
• overuse of ranges in dependecies,
• weak system of verifing third party libraries poms before they are placed in Maven repositories,
• not enough quality of some plugins,
• problems with availability of some artifacts, especially from Sun (cause licence limitations)

There are also psychological aspects of using Maven. For people who use Ant in daily work switching to Maven is hard especially for non HelloWorld projects. Others people have bad experience from early days of Maven when there weren't no good documentation, books, and lesser set of plugins. For these people it was easier did theirs projects in Ant. The last reason why some people don't like Maven is ignorance.

I agree with Pascal that "so much people can be blindly wrong". I can't imagine todays Java world without Maven.