4

Please correct me if I'm wrong. If no packing type is defined in a Maven pom.xml, jar lifecyle is used by default.

Every Maven packaging type has a default build lifecycle and associated default goals. (we can think of a goal as plugin + command)

Lifecycle Phase Goal

  • process-resources resources:resources
  • compile compiler:compile
  • process-test-resources resources:testResources
  • test-compile compiler:testCompile
  • test surefire:test
  • package jar:jar
  • install install:install
  • deploy deploy:deploy

My question is:
While defining a packaging type can we say that it is as if the pom.xml plugins section gets populated with the default plugins and goals for that packaging build lifecycle?

also:
If we define a plugin in the plugin section, say for example compiler plugin, and give its configurations, do these configurations override the plugin default configurations?

Bilesh Ganguly
  • 3,792
  • 3
  • 36
  • 58
GionJh
  • 2,742
  • 2
  • 29
  • 68

1 Answers1

5

If not packing type is defined in a maven pom.xml, jar lifecyle is used.

Almost correct, jar is not a life cycle, it's a packaging. Maven has three build life cycles (clean, default, site) which can be applied to any packaging.

As per official Maven model

packaging The type of artifact this project produces, for example jar war ear pom. Plugins can create their own packaging, and therefore their own packaging types, so this list does not contain all possible types.
Default value is: jar.

Every maven packaging type has a default build lifecycle

It has not a default life cycle, you invoke the default life cycle on its project. It has default bindings for the default life cycle, that is, plugins are already attached by default to phases of the defaul life cycle according to the defined packaging type.

One of the core concepts of Maven is convention over configuration. Its default bindings enforce this principle already providing executions of certain goals of certain plugins for a given packaging.
For instance, by default it is already desired to compile (via the maven-compiler-plugin and its compile goal during the compile phase), test (via the maven-surefire-plugin and its test goal during the test phase) and package (via the maven-jar-plugin and its jar goal during the package phase) your project when applying the default (jar) packaging.
(Note the pattern: I mentioned a plugin, a goal, a phase, that is, default bindings).

That is why the minimal pom can already do a lot: again, it's convention over configuration.

While defining a packaging type can we say that is as if the pom.xml plugins section gets populated with the default plugins and goals for that packaging build lifecycle?

Indeed, it would be like populating the build plugins section with executions of default attached plugins and goals and assigned to certain phases, using their default configuration.
Also note then, if you add a further execution of the same plugin and goal, it will be invoked on top of (after) the one specified by the default binding. See below how to prevent it, when required.

If we define a plugin in the plugin section, say for example compiler plugin, and give it configurations, do these configuration override the plugin default configurations?

You can define further plugins and executions of one or more of their goals, attached to a certain phase. Each execution can have a custom configuration. However, a configuration which is not within any execution section but declared as generic/global configuration will then be applied to any execution of the concerned plugin and as such also to the ones attached by default via packaging bindings.

From official POM reference on the configuration element

The default behavior is to merge the content of the configuration element according to element name. If the child POM has a particular element, that value becomes the effective value. if the child POM does not have an element, but the parent does, the parent value becomes the effective value.

And concerning the configuration element of an execution section:

configuration: Same as above, but confines the configuration to this specific list of goals, rather than all goals under the plugin.

That is why you often see a different source/target configuration for the maven-compiler-plugin, without any execution. It will be applied to the default execution of the compile (source code compilation) and testCompile (test code compilation) goals already attached via default bindings.

Additionally, you could even override the default binding and remove it from a certain phase by adding an execution for the same plugin, same goal, same execution id (most important point) and attach it to a different phase or to a non existing phase (or empty) phase. As such, you will disable the default plugin goal execution. You can use this trick to also add your plugin goal execution as first execution for the same phase: by disabling the default execution, adding your execution and then re-defining the default execution (with different id then). Maven will then follow the executions declaration order.

Check this SO answer on how execution ids are generated. The important point here would be, from official Maven documentation

each mojo bound to the build lifecycle via the default lifecycle mapping for the specified POM packaging will have an execution Id of default-goalName assigned to it

Community
  • 1
  • 1
A_Di-Matteo
  • 26,902
  • 7
  • 94
  • 128
  • 1
    What an answer ! thank you so much, this helped me really a lot ! :) – GionJh Apr 12 '16 at 12:08
  • I have only one additional doubt: Suppose I define another plugin compiler to be invoked bound to the compilation phase, what goal will executed first: the goal of the default compiler plugin or my plugin goal ? – GionJh Apr 12 '16 at 12:27
  • 1
    @GionJh default bindings are always executed first, if you need to execute your goal first, then you can use a trick: override the default execution id, bind it to empty phase (hence disable it), then define your execution and then re-define the default-binding execution. Then, the order of executions declarations will be used by maven. – A_Di-Matteo Apr 12 '16 at 12:29
  • What about build global options, I mean those defined inside buildsection but outside of ant plugin ? such as – GionJh Apr 12 '16 at 19:35
  • 1
    @GionJh those are used by maven at its core concerning standard and default input/output/folders for all plugins, all maven standard plugins (from Apache) use them, but additional plugins may ignore them, not require them or make them configurable, according to their needs. They enforce a certain project skeleton on which we normally execute plugin goals. – A_Di-Matteo Apr 12 '16 at 22:04
  • Thank you you'r helping me a lot, just out of curiosity: if we redefine those in our POMs, do they get overridden ? – GionJh Apr 13 '16 at 06:57
  • 1
    @GionJh yep, but better not to do so, in most of the cases default values are fine and people would not be surprised by misalignments – A_Di-Matteo Apr 13 '16 at 08:19
  • Thank you so much ! I would really appreciate it if you could help me also with this other question: http://stackoverflow.com/questions/36594632/maven-plugin-mojo-api-in-term-of-parameters – GionJh Apr 13 '16 at 09:56