Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Virgo » Maven best practices(discussion moved from https://bugs.eclipse.org/bugs/show_bug.cgi?id=329198)
Maven best practices [message #827132] Thu, 22 March 2012 23:38 Go to next message
Rafal Krzewski is currently offline Rafal KrzewskiFriend
Messages: 10
Registered: July 2009
Junior Member
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.
  • All your external dependencies should come from Maven Central. Maven Central stores artifacts forever, so the stuff you need to repeat your build in future won't disappear.
  • 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 Smile

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.
Re: Maven best practices [message #827368 is a reply to message #827132] Fri, 23 March 2012 08:24 Go to previous message
Glyn Normington is currently offline Glyn NormingtonFriend
Messages: 1222
Registered: July 2009
Senior Member
That's very helpful Rafal so I really appreciate the effort you have gone to in providing this information.

Although we won't be switching Virgo's build to Maven, we still use Maven when users build samples, so it's good to get an insight into best practices.

BTW your English seems excellent to me.
Previous Topic:Log display command?
Next Topic:Virgo tomcat Server 3.0.2 uploading war file problem
Goto Forum:
  


Current Time: Tue Apr 23 06:17:20 GMT 2024

Powered by FUDForum. Page generated in 0.03038 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top