Maven Learning Notes (iii)---operation and use

3. Maven's operation and use

MAVEN operates in two ways, one through the MVN command-line command and the Eclipse plugin using MAVEN. Because the Maven plugin that uses eclipse is easier to manipulate, this is just about using the MVN command-line operation.
3.1 Maven configuration file

MAVEN's main execution program is mvn.bat,linux under Mvn.sh, both of which are simple, and their common purpose is to collect some parameters and then use Java.exe to run Maven's main function. MAVEN also needs to have a configuration file named Settings.xml, which is placed in two places, one in the Conf directory of the MAVEN installation directory, for all users who use the MAVEN, which we call the Master profile, and the other in%userprofile%/ . M2/settings.xml, we become a user profile, valid only for the current user, and can overwrite the parameter contents of the master configuration file. There is also the project-level configuration information, which is stored in each MAVEN managed project directory, called Pom.xml, mainly for configuration project related content, of course, if necessary, users can also write some configuration in the Pom, overwriting the configuration file and user profile settings parameters content.

In general, settings files are configured to include global information such as the Repository library path, which can be found in the official website articles.
3.2 Creating a new project

To create a new MAVEN project, we need to assign several essential elements to our project, which are several elements of MAVEN's product coordinates: GROUPID, Artifactid, you can also specify the version and package name if you prefer. Let's look at a simple create command:

D:\WORK\TEMP>MVN archetype:create-dgroupid=com.abc-dartifactid=product1-darchetypeartifactid= Maven-archetype-webapp

First look at the delivery structure of the command-line arguments here, the weird-d parameter = value in the way that Java.exe is required. This command creates a Web project, and the directory structure is a standard MAVEN structure, as follows:
D:.
└─mywebapp
│pom.xml
│
└─src
└─main
├─resources
└─webapp
│index.jsp
│
└─web-inf
Xml

It is important to note that the layout of the directory structure is actually determined by the parameter Archetypeartifactid, because the incoming Maven-archetype-webapp if we pass in the other will create a different structure, the default value is Maven-archetype-quickstart, interested readers can refer to the more detailed list that I put in some of the commonly used lists here:
Artifact Group Version Repository Description
Maven-archetype-j2ee-simple org.apache.maven.archetypes A Simple Java application
Maven-archetype-marmalade-mojo org.apache.maven.archetypes A Maven plugin development project using marmalade
Maven-archetype-plugin org.apache.maven.archetypes A maven Java Plugin development Project
Maven-archetype-portlet org.apache.maven.archetypes A Simple portlet Application
Maven-archetype-profiles Org.apache.maven.archetypes
Maven-archetype-quickstart Org.apache.maven.archetypes
Maven-archetype-simple Org.apache.maven.archetypes
Maven-archetype-site-simple org.apache.maven.archetypes A Simple site Generation Project
Maven-archetype-site org.apache.maven.archetypes A more complex site project
Maven-archetype-webapp org.apache.maven.archetypes A Simple Java Web application
Maven-archetype-har Net.sf.maven-har 0.9 Hibernate Archive
Maven-archetype-sar Net.sf.maven-sar 0.9 JBoss Service Archive

You can refer to more detailed archetype:create Help and Archtype reference information.
3.3 Maven's multi-project management

Multi-project management is one of the main features of Maven, and it is no better for a large project to use MAVEN to manage the complex dependencies between them. There are two types of relationships between Maven project configurations: Inheritance relationships and referential relationships.
Maven defaults to the directory structure to set the inheritance of the Pom, that is, the subordinate directory of the POM default inheritance of the parent directory of the Pom. To set the relationship between the two is simple, the superior POM is set as follows:
<modules>
<module>ABCCommon</module>
<module>ABCCore</module>
<module>ABCTools</module>
</modules>

Keep in mind that the module here is the directory name, not the Artifactid of the sub-project. The sub-project is set up as follows:

<parent>
<groupId>com.abc.product1</groupId>
<artifactId>abc-product1</artifactId>
<version>1.0.0-SNAPSHOT</version>
</parent>
<artifactId>abc-my-module2</artifactId>
<packaging>jar</packaging>

In this way the two relate to each other, the inheritance relationship is set up, and all the parent project's configuration will automatically take effect in the subproject, unless the sub-project has the same configuration overrides. If you do not like layers of progressive directory structure to achieve inheritance, you can also add <relativepath&gt in the parent; /a-parent/pom.xml</relativepath> to make a relative directory of the parent project. The inheritance relationship is usually used to extract the common characteristics of the project, and by extracting the common characteristics, the configuration work of the sub-project can be greatly reduced.

Reference relationships are another way to reuse, and it's easy to configure reference relationships in Maven, adding a type that is dependent on the POM.
<dependency>
<groupId>org.sonatype.mavenbook</groupId>
<artifactId>persistence-deps</artifactId>
<version>1.0</version>
<type>pom</type>
</dependency>

However, either the parent project or the reference project, these projects must be installed in the local library with mvn install or mvn deploy, otherwise the dependency will not be found, and Eclipse compilation will also be wrong.

What needs to be put forward is that in the reuse process, the parent project's Pom can define the Dependencymanagement node, which holds the dependencies, but this dependency is only defined and does not really produce an effect, and if the subproject wants to use this dependency, it can be in its own Add a simplified reference to the dependency
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring</artifactId>
</dependency>

This method avoids the situation where the version number is flying.
3.4 Installing the library files into the MAVEN library

The ability to install library files is generally used in Maven, and one of our favorite hibernate is to use the JMX library, but because of Sun's license limitations, it cannot be included directly in Repository. So we use the MVN command to install the jar into our local repository.

MVN install:install-file-dgroupid=com.sun.jdmk-dartifactid=jmxtools-dversion=1.2.1-dpackaging=jar-dfile=/path/ To/file

If we want to install it in the company's repository, we need to use the command

MVN deploy:deploy-file-dgroupid=com.sun.jdmk-dartifactid=jmxtools-dversion=1.2.1-dpackaging=jar-dfile=/path/to/ File-durl=http://xxx.ss.com/sss.xxx-drepositoryid=release-repo

For our engineering outputs, if you need to place them in the company's repository, you can configure the POM to achieve
<distributionManagement>
<repository>
<id>mycompany-repository</id>
<name>mycompany repository</name>
<url>scp://repository.mycompany.com/repository/maven2</url>
</repository>
</distributionManagement>

The SCP method used here to submit the library file, there are other ways to use, please refer to the FAQ section. Then remember to include this in your settings.xml.

<settings xmlns= "http://maven.apache.org/SETTINGS/1.0.0"
Xmlns:xsi= "Http://www.w3.org/2001/XMLSchema-instance"
Xsi:schemalocation= "http://maven.apache.org/SETTINGS/1.0.0
Http://maven.apache.org/xsd/settings-1.0.0.xsd ">
...
<servers>
<server>
<id>mycompany-repository</id>
<username>jvanzyl</username>
<!--Default value is ~/.SSH/ID_DSA-
<privateKey>/path/to/identity</privateKey>
<passphrase>my_key_passphrase</passphrase>
</server>
</servers>
...
</settings>



3.5 maven Variables

MAVEN defines a number of variable properties, refer to Here Http://docs.codehaus.org/display/MAVENUSER/MavenPropertiesGuide

Built-in properties
${basedir} represents the directory containing Pom.xml
${version} equivalent to ${project.version} or ${pom.version}
Pom/project Properties
All elements in the POM can be used with project. Prefixes are referenced, the following are some of the common
${project.build.directory} results in the path to your "target" dir, which is the same as ${pom.project.build.directory}
${project.build. Outputd Irectory} results in the path to your "target/classes" dir
${project.name} refers to the name of the project.
${project.version} refers to the version of the project.
${project.build.finalname} refers to the final name of the "the file created when" The built project is packaged
Local User settings
All of the settings in the settings.xml are available through settings. Prefix for reference
${settings.localrepository} refers to the path of the user ' s local repository.
${maven.repo.local} also works for backward compatibility with MAVEN1??
Environment variables
The environment variables of the system are via Env. Prefix reference
${env. M2_home} returns the Maven2 installation path.
${java.home} Specifies the path to the current jre_home environment use with relative paths to get for example:
<jvm>${java.home}.. /bin/java.exe</jvm>
Java System Properties
All Java System Properties defined in the JVM.
Custom properties defined by the user in the POM
<project>
...
<properties>
<my.filter.value>hello</my.filter.value>
</properties>
...
</project>
The reference ${my.filter.value} will get the value Hello
Variables for superior projects
The variables in the pom of the superior project are referenced with the prefix ${project.parent}. The version of the superior project can also refer to this: ${parent.version}.

Use of 3.6 maven

We already know that Maven has pre-defined many phases (phase), each of which is attached to these phases, and when it enters a stage, it invokes the functions that run the related plugins. Let's look at the full Maven lifecycle first:
Life Cycle Phase Description
Validate verify that the project is correct and that all necessary information is available for complete construction
Generate-sources generate all the source code that needs to be included in the compilation process
Process-sources processing source code, such as filtering some values
Generate-resources generate all resource files that need to be included in the packaging process
Process-resources copy and process the resource file to the target directory, ready to package
Compile compiling the source code of the project
Process-classes post-processing of compiled generated files, such as byte-code enhancement for Java classes (bytecode enhancement)
Generate-test-sources generate all test sources included in the test compilation process
Process-test-sources processing test source, such as filtering some values
Generate-test-resources the resource files required to generate the test
Process-test-resources copy and process the test resource file to the test target directory
Test-compile compiling test source to test target directory
Test runs the tests using the appropriate unit test framework. These tests should not require code to be packaged or published
Prepare-package do some of the necessary things to pack before you actually pack. This usually results in a processed version of the expanded package (which will be implemented in Maven 2.1+)
The package packages the compiled code into a distributable format, such as Jar,war, or ear
Pre-integration-test performs some actions that are required before the integration test runs. Environments where integration testing is required
Integration-test if necessary, process the package and publish it to an environment where the integration test can run
Post-integration-test performs some actions that are required after the integration test runs. such as cleaning the integration test environment.
Verify performs all checks, verifies that the package is valid and complies with the quality specification
Install the package to the local repository for other local projects to be used as dependent
Deploy copies the final package to the remote repository, shared to other developers and projects (usually associated with a formal release)

The MAVEN core plugin list can refer to http://maven.apache.org/plugins/index.html. Here are just a few common plug-ins and their configuration parameters:

Clean Plugin
Contains only one goal called Clean:clean, responsible for cleaning up the files created at the time of the build. The default cleanup location is specified by several variables such as the path project.build.directory, Project.build.outputDirectory, Project.build.testOutputDirectory, and Project.reporting.outputDirectory.
Compiler plug-in
Contains 2 goal, respectively, Compiler:compile and Compiler:testcompile. Here you can see the specific parameter settings for both: Compile, testcompile.
Surefire Plug-in
A plug-in that runs a unit test case and can generate a report. Contains a goal for surefire:test. The main parameter testsourcedirectory is used to specify the test case catalog, reference the full usage help
Jar
Responsible for packaging the project output into a jar file. Contains two goal, respectively, Jar:jar, Jar:test-jar. Two goal is responsible for getting all the resources from the Classesdirectory or testclassesdirectory, and then outputting the jar file to OutputDirectory.
War
Responsible for packaging the war file. The common goal has war:war, which is responsible for packaging all resources from warsourcedirectory (default ${basedir}/src/main/webapp) to OutputDirectory.
Resources
Responsible for copying various resource files, commonly used goal has resources:resources, is responsible for copying the resource files to OutputDirectory, the default is ${project.build.outputdirectory}.
Install
is responsible for adding project output (install:install) or a specified file (install:install-file) to the native library%userprofile%/.m2/repository. You can ask for help with Install:help.
Deploy
Responsible for adding project output (Deploy:deploy) or a specified file (deploy:deploy-file) to the company library.
Site
The project all documents generated by the site, the generated site interface by default and Apache project site similar, but its documents in Doxia format, currently does not support DocBook, need to use other plug-ins to support. It should be noted that the Site command processing in the MAVEN 2.x series is different from the maven3.x, and in the old version, all reports in the reporting node can be generated with the MVN site command, but reporting is obsolete in maven3. This should be used as the content of the Maven-site-plugin configuration. For more information, refer to Http://www.wakaleo.com/blog/292-site-generation-in-maven-3

Original path: http://blog.csdn.net/houpengfei111/article/details/9142869

Maven Learning Notes (iii)---operation and use