4

What is the difference between the "mvn install" command, versus the use of the jar:jar plugin ?

Its clear that "install" seems to build a jar, and so, I am wondering what the need for the jar:jar plugin would be.

jayunit100
  • 17,388
  • 22
  • 92
  • 167
  • 1
    [jar:jar](http://stackoverflow.com/a/2788050/829571) vs [install](http://stackoverflow.com/questions/10533828/what-does-mvn-install-in-maven-exactly-do). – assylias Jan 14 '13 at 22:47

3 Answers3

18

There are two types of things you can specify on the maven command line:

  • lifecycle phases (these do not include a : character)

  • plugin goals (these include at least one : character, depending on how fully you specify the plugin, it could be short-name:goal or groupId:artifactId:goal or groupId:artifactId:version:goal)

There are three lifecycles: default, clean and site. Each lifecycle consists of a series of phases. When you specify a phase in a lifecycle then Maven will execute in order all the phases in that lifecycle up to and including the specified phase.

When you specify a plugin goal then that plugin goal is invoked and only that plugin goal.

Maven has a concept of a packaging which defines a default set of plugin bindings to lifecycle phases. For example the jar packaging (which is default unless your pom.xml includes a <packaging>...</packaging> element) by default binds jar:jar to the package phase and binds install:install to the install phase.

So when you type

$ mvn package

Maven will run all the way through the lifecycle phases executing plugins that are bound (either from the lifecycle or by specifying plugin executions in the pom) as it goes along.

When you type

$ mvn jar:jar

Maven will just run the jar plugin's jar goal.

The lifecycle is 99 times out of 100 the one you want to use.

Here are the times you would typically want to invoke plugin goals directly

  • jetty:run to start a webapp server

  • surefire:test to quickly re-run the tests (usually with -Dtest=... to specify the specific one

  • release:prepare release:perform to release your code

  • versions:... to do some updating or querying of version related stuff, e.g. versions:display-plugin-updates

  • ship:ship or cargo:deployer-deploy to push (ship) your built artifacts to a hosting environment

Stephen Connolly
  • 13,872
  • 6
  • 41
  • 63
  • That was a great answer. I literally found it easier to understand than the official documentation. I'd also like to know, what's the order of operations if there's multiple plugins bound to the same phase? Can you define your own lifecycles? At my company, we want the wsgen plugin to run manually and w/o other phases. My solution was to put it in a profile, but I would have preferred to run it like `mvn wsgen` – Daniel Kaplan Jan 15 '13 at 08:10
  • 1
    The order of plugin executions within a phase is officially `undefined`. You can define your own lifecycle, but there are limitations: For one you need to add the lifecycle through an `` (there are two ways to do that) and secondly, if a multi-module build has two custom lifecycles which use the same lifecycle phase name, all hell breaks loose. Typically the `wsgen` style tasks I solve with a profile that has a default phase and bind plugins to early phases, e.g. `initialize' and 'validate'... then `mvn -Pwsgen` though you are heading towards anti-pattern land with that ;-) – Stephen Connolly Jan 15 '13 at 11:19
  • @StephenConnolly how can it be officially undefined with bugs like [this one](http://jira.codehaus.org/browse/MNG-2258) and [this one](http://jira.codehaus.org/browse/MNG-3719)? See also [this answer](http://stackoverflow.com/a/3613070/365237) by Pascal Thivent - so since Maven 3.0.3, it should be the pom.xml order, right? – eis Feb 01 '13 at 16:43
  • @eis: IIRC the discussions I have had have centred around the fact that we don't want a defined order *within* a phase. **However**, the fact that it was in that order for a long time and people therefore have builds depending on the side-effect of implementation probably means that we will not be able to close that stable door... the horse has already bolted... but that does not take away from the message, namely, that you should not be relying on pom order for defining the executions within a phase... and the pom version 5 should provide a mechanism to sequence within a phase – Stephen Connolly Feb 01 '13 at 16:59
  • @StephenConnolly those bugs were about order within a phase. I read those links so that previously it was undefined (both officially and in practice), but since 3.0.3 it's been defined within a phase as the order it is defined in a pom. So AFAIK it is vice versa: previously people couldn't rely on order, but they needed the feature, so now it is in pom order. – eis Feb 02 '13 at 11:25
  • I view that as a hack solution. Plus there are people who can't move to m3 yet (why I don't know ;-) ) so safer to not make your build rely on such effects – Stephen Connolly Feb 02 '13 at 12:02
2

install puts the artifact in your local (on your machine) maven repository, jar:jar does not. If you call jar:jar on a library then try to reference that library in another project, it will not be in your local repository.

Also note that mvn package is a cleaner way to do packaging, rather than using jar:jar.

Peter Elliott
  • 3,273
  • 16
  • 30
  • 1
    indeed, that will select the correct plugin based on the `` value of the pom.xml – JoG Jan 14 '13 at 22:52
2

mvn install command will "execute" the maven lifecycle up to the install phase. It means that all previous phases will be executed (including the package phase).

On a simple maven jar project, the package phase is bind to the maven-jar-plugin. And so executing mvn install will execute at some point jar:jar.

ben75
  • 29,217
  • 10
  • 88
  • 134