Although I have some experience about Maven 2, this is a simple summary. > Maven /ˈmeɪv_ə_n/
groupid:artifactid:packaging:version:scope such as: org.springframework:spring:jar:2.5.6:compile
org.mockito:mockito-core:jar:4.7:test Maven provides the following standard scope:
Scope Description compile Needed for compilation, included in packages. test Needed for unit tests, not included in packages. provided Needed for compilation, but provided at runtime by the runtime container. system Needed for compilation, given as absolute path on disk, and not included in packages. import An inline inclusion of a POM-type artifact facilitating dependency-declaring POM snippets.
Lifecycles, Phases, Plugins, Goals
Lifecycles represent a well-recognized flw of steps (Phases) used in software assembly. Each step in a lifecycle flow is called a phase. Zero or more plugin goals are bound to a phase. A plugin is a logical grouping and distribution (often a single JAR) of related goals, such as JARing. A goal, the most granular step in Maven, is a single executable task within a plugin. For example, discrete goals in the jar plugin include packaging the jar (jar:jar), signing the jar (jar:sign), and verifying the signature (jar:sign-verify).
Maven provides 3 built-in lifecycles: clean, default, site.
The following lists all build phases and its default goals bound to them.
|Phrase||Default goal bindings||Phase description|
|pre-clean||executes processes needed prior to the actual project cleaning|
|clean||maven-clean-plugin:clean||remove all files generated by the previous build|
|post-clean||executes processes needed to finalize the project cleaning|
|Phase||Default goal bindings||Phase description|
|packaging ejb/ejb3/jar/par/rar/war||packaging ear||packaging maven-plugin||packing pom|
|validate||validate the project is correct and all necessary information is available.|
|initialize||initialize build state, e.g. set properties or create directories.|
|generate-sources||generate any source code for inclusion in compilation.|
|process-sources||process the source code, for example to filter any values.|
|generate-resources||maven-ear-plugin:generate-application-xml||maven-plugin-plugin:descriptor||generate resources for inclusion in the package.|
|process-resources||maven-resources-plugin:resources||maven-resources-plugin:resources||maven-resources-plugin:resources||copy and process the resources into the destination directory, ready for packaging.|
|compile||maven-compiler-plugin:compile||maven-compiler-plugin:compile||compile the source code of the project.|
|process-classes||post-process the generated files from compilation, for example to do bytecode enhancement on Java classes.|
|generate-test-sources||generate any test source code for inclusion in compilation.|
|process-test-sources||process the test source code, for example to filter any values.|
|generate-test-resources||maven-resources-plugin:testResources||maven-resources-plugin:testResources||create resources for testing.|
|process-test-resources||copy and process the resources into the test destination directory.|
|test-compile||maven-compiler-plugin:testCompile||maven-compiler-plugin:testCompile||compile the test source code into the test destination directory|
|process-test-classes||post-process the generated files from test compilation, for example to do bytecode enhancement on Java classes. For Maven 2.0.5 and above.|
|test||maven-surefire-plugin:test||maven-surefire-plugin:test||run tests using a suitable unit testing framework. These tests should not require the code be packaged or deployed.|
|prepare-package||perform any operations necessary to prepare a package before the actual packaging. This often results in an unpacked, processed version of the package. (Maven 2.1 and above)|
|package||maven-ejb-plugin:ejb / maven-ejb3-plugin:ejb3 / maven-jar-plugin:jar / maven-par-plugin:par / maven-rar-plugin:rar / maven-war-plugin:war||maven-ear-plugin:ear||maven-jar-plugin:jar maven-plugin-plugin:addPluginArtifact Metadata||maven-site-plugin:attach-descriptor||take the compiled code and package it in its distributable format, such as a JAR.|
|pre-integration-test||perform actions required before integration tests are executed. This may involve things such as setting up the required environment.|
|integration-test||process and deploy the package if necessary into an environment where integration tests can be run.|
|post-integration-test||perform actions required after integration tests have been executed. This may including cleaning up the environment.|
|verify||run any checks to verify the package is valid and meets quality criteria.|
|install||maven-install-plugin:install||maven-install-plugin:install||maven-install-plugin:install||maven-install-plugin:install||install the package into the local repository, for use as a dependency in other projects locally.|
|deploy||maven-deploy-plugin:deploy||maven-deploy-plugin:deploy||maven-deploy-plugin:deploy||maven-deploy-plugin:deploy||done in an integration or release environment, copies the final package to the remote repository for sharing with other developers and projects.|
|Phase||Default goal bindings||Phase description|
|pre-site||executes processes needed prior to the actual project site generation|
|site||maven-site-plugin:site||generates the project’s site documentation|
|post-site||executes processes needed to finalize the site generation, and to prepare for site deployment|
|site-deploy||maven-site-plugin:deploy||deploys the generated site documentation to the specified web server|
we set the packaging for your project via the equally named POM element <packaging>. Some of the valid packaging values are jar, war, ear and pom. If no packaging value has been specified, it will default to jar.
Phase and goal binding
A goal may be bound to zero or more build phases. A goal not bound to any build phase could be executed outside of the build lifecycle by direct invocation.
Moreover, if a goal is bound to one or more build phases, that goal will be called in all those phases.
Furthermore, a build phase can also have zero or more goals bound to it. If a build phase has no goals bound to it, that build phase will not execute.
Usually, plugin bind its goals on default phases. That’s defined on plugin jar’s MATE-INF/maven/plugin.xml.
Let’s see the plugin.xml of maven-compiler-plugin.jar:
<plugin> <mojos> <mojo> <goal>compile</goal> .... <phase>compile</phase> .... </mojo> <mojo> <goal>help</goal> .... </mojo> <mojo> <goal>testCompile</goal> .... <phase>test-compile</phase> .... </mojo> </mojos> </plugin>
maven-compiler-plugin defines 3 goals, and “compile” and “testCompiler” goals have the default phase, but “help” goal not.
But a goal can be bound on different phases which can be reconfigured by plugin configuration section.
... <plugin> <groupId>com.mycompany.example</groupId> <artifactId>display-maven-plugin</artifactId> <version>1.0</version> <executions> <execution> <phase>process-test-resources</phase> <goals> <goal>time</goal> </goals> </execution> <execution> <phase>process-resources</phase> <goals> <goal>anotherGoal</goal> <goal>anotherGoalAgain</goal> </goals> </execution> </executions> </plugin> ...
The default goal codifis the author’s intended usage of the build script. Only one goal or lifecycle can be set as the default.
<project> [...] <build> <defaultGoal>install</defaultGoal> </build> [...] </project>
Execute a Phase or Goal
If you ask Maven to run a specific goal, then only that goal is run.
For org.apache.maven:maven-***-plugin, you can run it using the plugin-prefix for short. > mvn <plugin-prefix>:<goal> or
For your customized plugins, run it: > mvn <plugin-group-id>:<plugin-artifact-id>[:<plugin-version>]:<goal> For example: > mvn compiler:compile jar:jar This example runs two plugin goals: compilation of code, then JARing the result, skipping over any intermediate steps.
Conversely, if you ask Maven to execute a phase, all phases and bound plugin goals up to that point in the lifecycle are also executed. This example requests the deploy lifecycle phase, which will also execute the verifiation, compilation, testing and packaging phases. > mvn deploy
Profies are a means to conditionally turn on portions of Maven confiuration, including plugins, pathing and confiuration. The most common uses of profies are for Windows/Unix platform-specifi variations and build-time customization of JAR dependencies based on the use of a specifi Weblogic, Websphere or JBoss J2EE vendor.
<project> ... <profiles> <profile> <id>YourProfile</id> ...settings, build, plugins etc... <dependencies> <dependency> <groupId>com.yourcompany</groupId> <artifactId>yourlib</artifactId> </dependency> <dependencies> </profile> </profiles> ... </project>
Profiles can be activated manually from the command line or through an activation rule (OS, fie existence, Maven version, etc.).
Profiles are primarily additive, so best practices suggest leaving most off by default, and activating based on specific conditions.
Manual Profie Activation > mvn –P YourProfie Automatic Profie Activation
<project> ... <profiles> <profile> <id>YourProfile</id> ...settings, build, etc... <activation> <os> <name>Windows XP</name> <family>Windows</family> <arch>x86</arch> <version>5.1.2600</version> </os> <fie> <missing>somefolder/somefie.txt</missing> </fie> </activation> </profile> </profiles> ... </project>