tags:

views:

131

answers:

3

Hi all, I'm confused about the use of maven in development and production environments - I'm sure it's something simple that I'm missing. Grateful for any help..

I set up maven inside eclipse on my local machine and wrote some software. I really like how it's made things like including dependent jars very easy.

So that's my development environment. But now I want to release the project to production on a remote server. I've searched the documentation, but I can't figure out how it's supposed to work or what the maven best practice is.. Are you supposed to:

a) Also be running maven on your production environment, and upload all your files to your production environment and rebuild your project there? (Something in me baulks at the idea of rebuilding 'released' code on the production server, so I'm fairly sure this isn't right..)

b) use mvn:package to create your jar file and then copy that up to production? (But then what of all those nice dependencies? Isn't there a danger that your tested code is now going to be running against different versions of the dependent jars in the production environment, possibly breaking your code? Or missing a jar..?)

c) Something else that I'm not figuring out..

Thanks in advance for any help!

+2  A: 

You need to look into the Maven Assembly Plugin and the Maven Release Plugin.

Jason Nichols
+4  A: 
  • You're supposed to have your code under version control (and you never "upload" files to another machine, you "download" them from the Version Control System if required).

  • You're supposed to package your code in a format (a WAR, an EAR, another kind of bundle) that can be deployed on the production environment for execution. Such bundles typically include the dependencies. To build more complex bundles, the Maven Assembly Plugin can help.

  • Maven generated artifacts (JARs, WARs, whatever) should be shared via a remote repository (and thus deployed - I mean mvn deploy here - to this remote repository). A remote repository can be a simple file system served via a web server or a more advanced solution like Nexus.

  • Development is usually done using SNAPSHOT dependencies (e.g. 1.0-SNAPSHOT). At release time, you're supposed to change the version into a "fixed" version (e.g. 1.0) and some other bits from your pom.xml, run the build to check that everything is ok, commit the modified pom.xml, create a tag in the VCS, promote the versions to a new SNAPSHOT (e.g. 1.1-SNAPSHOT) in the pom.xml, commit the new pom.xml in the VCS. The entire process require some work but this can be automated using the Maven Release Plugin.

  • On the production environment, get the artifacts to be deployed from the remote repository and deploy them (some projects automate the deployment to the production server using Maven but that's another story).

Of course, there are variations around this (deployment to production is most of time company specific) but the general idea is there.

Pascal Thivent
+1  A: 

When building artifact you usually state what scope the dependency has. In default scope it should be packaged in your archive. If you do not want it, use scope "provided" - in such case you have to prepare runtime environment providing the dependency. It's generaaly a bad idea to rebuild a package only for deployment.

As for deploying, you can use maven's antrun plugin to copy files locally or via scp .

binary_runner