Recently a discussion of Virgo Tooling / PDE integration diverted to Maven and it's best practices. The bug has many people on CC list, so I decided to move further discussion of Maven here.

Glyn asked about Maven best practices reference.

While there is no such page in official Maven documentation (http maven.apache.org/) there is plenty of information on that site. Unfortunately it's not easy to use unless you have fairly good idea what you are looking for.

A better source of information on "how do I fix my build" are books. There is the Sonatype book http www.sonatype.com/books/mvnref-book/reference/ available free of charge in digital form.

Another interesting book is Maven 2 Effective Implementation http www.packtpub.com/apache-maven-2-effective-implementation/book#indetail
It's been published in 2009 and a things have changed since (Maven 3 was published and Sonatype Nexus emerged as #1 repository manager) but the basics of "Maven Way" of build management have not changed. Chapter 9 of that books gives a comprehensive list of best practices. I haven't read the book but the TOC looks very solid, and Brett Porter was one of key Maven commiters, so I think you won't be disappointed if you get this book.

Now, if you don't have time for studying and/or would like my personal opinion, here's a list of a few things that contribute to sane Maven build.

Don't store any binaries in source repositories. All build dependencies need to come from Maven repositories.

If you need to use artifacts that are not available on Central, there are a few things that you can do:

convince the authors to put their stuff on Central

if they are not interested, or the project is defunct, put their stuff on Central yourself (Non Manintainer Upload), here's how: http www.sonatype.org/central/participate

if you can't be bothered to do either, put the external artifacts in your own repository. Running your own repository server makes it very easy. When you have them in your own repository, you have control over artifact retention. If you are collecting only released versions, keeping them forever should be a viable option even for a fairly large project/organization.

Don't depend on external SNAPSHOT artifacts. Ever. If you stick to using Maven Central (and optionally your own repository with 3rd party release artifacts) external SNAPSHOTS won't be available for your builds, which is good and will save you a lot of trouble.

If you must use some 3rd party code that is not released, convince the author to publish a release and put it on Central, and use it from there. Tracking a moving target is not what you want to do when developing your own code.

If the above cannot be done, build the 3rd party code from source repository and deploy it to your own Maven repository. Preferably build the code using a CI system and deploy the binaries using a repository manager. You need to establish SNAPSHOT artifacts retention policy, otherwise server's disk is going to overflow. It will happen sooner than you think.

If the size of your codebase permits, let every person on the team pull all sources from SCM and build them locally. If they are using Eclipse + m2e, only incremental recompiles will occur during normal work. This way everybody is on the same page in terms of the "next release" code.

If the project is so large that a single developer has only a subset of modules in their IDE at a time, but still needs up-to-date binaries for other modules, CI system coupled with repository manager are to rescue. This way each time code is pushed to master branch, new binaries will be produced and published for everyone to use. With this setup you'll need to use "update always" snapshot policy in snapshot repository definition in the POMs.

I hope this is helpful. If you have any further questions, ask away

PS. I hope my attempts at humor did not come across as offensive. I'm not a native English speaker, so please bear with me.