I wrote a lot today, and I have time to organize the format. This format is ok for typesetting in logdown. ITeye did not rearrange, if you are interested, you can go to see my Logdown http://yuezaixz.logdown.com/posts/165674-not-proud-of-maven-life-cycle-as-well-as-those-in -the-plugin-details .
I have been very distressed recently. When I enter and exit project management, I have encountered such big problems: tight schedule, insufficient resources, difficult coordination across departments in functional organizations, and insufficient product requirements and design stages (I also accepted the project after requirements and design). Etc., but these are all environmental issues. I think it is valuable and meaningful to manage these issues. I think the biggest problem lies in people. These people include the people below and those above.
[size=20px;]The way team members work makes me feel like they are doing useless work all day[/size]
There are loopholes in the function implementation. These are normal things. The problem is that this problem is completely unusable. Why don't you finish it and test it yourself Down? If this is not so outrageous, then the interface is chaotic, and it is not implemented according to the static page of the artist. The interface is always what you see is what you get. The reluctance to self-test after finishing the function is also because of the behavior of hiding one's ears and stealing the bell for fear of encountering problems.
In addition, after asking many times whether the code has been submitted to start building the project, it is found that there is still code that has not been submitted. Then, the update package of the database script can also be mixed with some wrong symbols, causing the script to fail to run. Then, the submitted page often has one more tag and one less tag, causing frequent problems under IE6, and then again...
In short, It is the constant introduction of confusion, which increases my countless time in checking the problem, and the problem will continue to recur after the problem is revised, or new problems will be introduced.
There is also the issue of overtime, so much confusion has been introduced, and the scheduled tasks have not been completed and they are unwilling to work overtime. After being forced to stay by me, I ran away while I was eating. This sense of responsibility is completely unacceptable to me.
I know that team building needs to go through periods of shock. Technical problems can be made up, but I don’t think it’s easy to correct mentality problems and responsibility problems.
They may also be unhappy at work, because there is no demand and design, lack of art support, and plans are always changing, which will affect the enthusiasm for work. At first, I was also troubled by these, but later I felt that these environmental factors were all surmountable and challenges. But I don't see them changing in the face of difficulties at all. And I would choose to give up my lunch break, even work immediately after lunch and dinner, and work overtime without interruption for a month. In fact, overtime is always me alone.
[size=20px;] The leader wants to do well, and he really pays attention, but he is not willing to invest [/size]
I am a person who is keen on technology. If the leader arranges this year's task to complete the project, then I will conscientiously arrange the annual plan, Make plans and re-code, and leaders frequently change work content and plans due to changes in the situation. Then I work for a year and earn a year's salary, but is my work really worth it? Are you really happy doing it? (PS. I haven’t raised my salary for one year after I joined the company, because the company has not given an example of a salary increase for employees who have turned into a regular member for one year. In fact, the salary is the same as that of me two years ago. I just continue to do it because I feel it is worthwhile and challenging)
--- ----------------------------------Dividing line-------------- -----------------------------
[size=20px;]Life cycle[/size]
[size=16px;] What is life Cycle [/size]
Developers clean up, compile, test, and deploy the project every day, which is the life cycle of the project build.
Maven's lifecycle is all about abstracting and agreeing on all build processes.
Maven's life cycle is abstract, equivalent to the template pattern of the design pattern. Just define the overall algorithm, the real work in the life cycle is still done by the plug-in.
Plugin bindings are further divided into built-in bindings and default bindings.
[size=16px;]Three life cycles[/size]
Maven has three independent life cycles, namely clean, default, and site.
Clean is to clean the project;
Default is to build the project;
Site is to build the project site.
The three life cycles are independent of each other. For example, calling a certain stage of the clean life cycle (the stage will be described in detail later) will not affect the default life cycle.
[size=16px;] Phases of the life cycle [/size]
Each life cycle contains some phases (phase), these phases are sequential, and the later ones depend on the previous ones. Take the clean life cycle as an example, which includes pre-clean, clean and post-clean. When the user calls clean, the pre-clean and clean phases are called.
[size=16px;]Life cycle and stage list[/size]
The Clean life cycle consists of three stages
pre-clean Perform some work that needs to be done before
clean Clean Remove all files generated by the last build
Post-clean Execute Some work that needs to be completed immediately after clean
The various stages of the Default life cycle
most of the important stages are in this cycle:
validate
generate-sources
process-sources
generate-resources
process-resources Copy and process resource files to the target directory, ready for packaging.
compile compiles the source code of the project.
process-classes
generate-test-sources
process-test-sources
generate-test-resources
process-test-resources Copies and processes resource files to the target test directory.
test-compile Compiles test source code.
process-test-classes
test runs tests with a suitable unit testing framework. These test code will not be packaged or deployed.
The prepare-package
package accepts compiled code and packages it into a distributable format, such as a JAR.
pre-integration-test
integration-test
post-integration-test
verify
install Install the package to the local repository for other projects to depend on.
deploy copies the final package to a remote repository for other developers to share with the project.
Stages of the Site life cycle
pre-site performs some work that needs to be done before generating site documentation
site generates site documentation for the project
post-site performs some work that needs to be done after site documentation is generated and prepares for deployment
site-deploy will The generated site document is deployed to a specific server.
For
details, please refer to the [Lifecycle Reference](http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html) of the introduction page on the Maven official website. ).The content of the chapter section.
[size=16px;]Command line[/size]
### mvn clean
executes the clean phase of the clean cycle. The actual execution phases include the pre-clean and clean phases of the clean cycle.
### mvn test
invokes the test phase of the default life cycle. The actual execution of the default life cycle knows all phases of the test.
### mvn clean install
executes the pre-clean and clean phases of the clean lifecycle, as well as all phases from default until install.
### mvn clean deploy site-deploy
Execute the pre-clean and clean phases of the clean life cycle, as well as all phases of the default, and all phases of the deploy life cycle.
[size=20px;]Plugin[/size]
[size=16px;] Plugin goal [/size]
In order to reuse code, the plugin itself often completes multiple tasks. For example, the maven-dependency-plugin plugin can analyze project dependencies, list dependency trees, analyze dependency sources, list all resolved dependencies, and more. A lot of code in these functions is actually reused, so for reuse, they are integrated into a plug-in.
Therefore, the goal of each plugin is the functionality of a plugin. The goal of dependency:analyze is to analyze, and the function is to analyze dependencies. The function of the target tree of dependency:tree is to list the dependency tree.
[size=16px;]Writing[/size]
Dependency:tree is a common way of writing. The prefix of the plug-in is in front of the colon, and the goal of the plug-in is behind. For example, compile: compile is the compile goal of maven-compiler-plugin.
[size=16px;] Binding of plug-ins [/size]
Maven's life cycle and plug-ins are bound to each other to complete the actual construction. For example, the task of project compilation is what the compile phase of the default life cycle does, and the compile goal of the maven-compile-plugin plugin completes this function. Therefore, binding them will achieve the compilation goals of the project.
The binding of the plugin has been mentioned in the previous chapter 1.1, and it is divided into built-in binding and custom binding.
[size=16px;] Built-in bindings [/size]
Built-in bindings are preset and do not require user configuration. Maven has already bundled many plugins at various stages of the life cycle to complete the main function of the build. For example, the clean phase of the clean lifecycle is bound to the clean goal of the maven-clean-plugin.
There are some special ones, such as the package phase of the default life cycle, which is bound by maven-jar-plugin:jar by default.
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
[size=16px;]References[/ The specific content of size]
can also be seen in the [Setting Up Your Project to Use the Build Lifecycle](http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html) chapter.
The command output
can also be seen from the output of the Maven console when the command is executed, and you can also know which plugin goals are executed in a specific stage.
Custom plugin
users bind plugin goals to stages through configuration. The specific configuration is as follows:
org.codehaus.modellomodello-maven-plugin1.4modello-javaverifyjava
groupIdle, artifactId, and version are the dependency coordinates of the plugin.
Each execution sub-element under Executions can be used to configure the execution of a task.
In the example, an id of modello-java is configured, and the configuration phase configuration is bound to the verify life cycle phase, and is executed through the specified target configured in goals.
Run mvn verify to see that the plugin is executed.
### Query plugin binding
You can query the detailed information of the plugin that should be bound.
After mvn help:describe -Dplugin=org.apache.maven.plugins:maven-source-plug
in:2.1.1 –Ddetail command, it shows
source:test-jar-no-fork
Description: This goal bundles all the test sources into a jar archive.
This goal functions the same as the test-jar goal but does not fork the
build, and is suitable for attaching to the build lifecycle.
Implementation: org.apache.maven.plugin.source.TestSourceJarNoForkMojo
Language: java
Bound to phase: package
Available parameters:
archive
The archive configuration to use. See Maven Archiver Reference.
Bound to phase: package indicates that the default binding life cycle phase of the plugin target is package.
[size=16px;] Plugin configuration [/size] When
the command line plugin configuration
runs the command, add -D (parameter that comes with java, its function is to set a java system property through the command line), which realizes the configuration of the plugin parameters .
For example, maven-surefire-plugin provides a maven.test.skip parameter, when the value is true, it will skip the execution of the test. So
D:\workspace\hello-world>mvn install -Dmaven.test.skip=true
will skip the testing phase.
The console output contains the following information.
[INFO] --- maven-surefire-plugin:2.10:test (default-test) @ hello-world ---
[INFO] Tests are skipped. Not all parameters
in the global configuration of the plugin in the POM
can be executed from the command line, some The parameters will not change from the creation of the project to the release of the project, and can be configured in the pom file at one time. Such as java 1.5 this parameter.
...
org.apache.maven.plugins
maven-jar-plugin
2.1
1.5 source >
1.5 target >
In this way, this configuration can be used regardless of whether it is bound to the compile stage or to the test stage, and is eager to compile with java1.5.
The plugin task configuration in the POM
The following configuration allows Maven to execute tasks during the binding phase. You can also bind multiple execetuions to let Maven perform different tasks in different life cycles.
The following example is an ant script plugin, which is used to execute the ant command and output the directory being created for prompt information.
maven-antrun-plugin
echodir
run
verify
false
Build Dir: ${project.build.directory}
Note: inherited: whether this plugin configuration will be applied to poms, those projects that inherit from this.
[size=16px;] Get with command Plug-in description information [/size]
After the mvn help:describe -Dplugin=org.apache.maven.plugins:maven-source-plug
in:2.1.1 command, the plug-in description information is displayed.
```
D:\workspace\hello-world>mvn help:describe -Dplugin=org.apache.maven
.plugins:maven-compiler-plugin:2.1
Name: Maven Compiler Plugin
Description: The Compiler Plugin is used to compile the sour
project.
Group Id: org.apache.maven.plugins
Artifact Id: maven-compiler-plugin
Version: 2.1
Goal Prefix: compiler
This plugin has 3 goals:
compiler:compile
Description: Compiles application sources
compiler:help
Description: Display help information on maven-compiler-pl
Call
mvn compiler:help -Ddetail=true -Dgoal=
to display parameter details.
compiler:testCompile
Description: Compiles application test sources.
For more information, run 'mvn help:describe [...] -Ddetail'
```
Describes the coordinates and target of the plugin. You can also get more information by adding the -Ddetail parameter at the end.
[size=16px;] The command line calls the plugin [/size]
For example, mvn dependency:tree.
[size=16px;] Plug-in parsing mechanism [/size]
Plug-in repository
When we use the goal of the Maven plugin, we use its prefix (abbreviation). Once there is a problem with executing the command, it is difficult to locate which plugin is running wrong. . Here we take a look at its plug-in plug-in mechanism. Why put repository dependency resolution and plugin resolution together, because they do have similarities. The components of the plug-in also exist in the Maven library based on the coordinates. When needed, the relevant plug-ins are required from the local warehouse. If they do not exist, they are found from the remote warehouse and downloaded to the local after they are found.
```
•
•
• central
• Maven plugin
• htpp://repo1.maven.org/maven2
• default
•
• true
•
•
• false
•
•
•
````
### The default groupId
plugin configuration of the plugin can omit the groupId, and the default is the official Maven plugin.
For example,
maven-antrun-plugin
echodir
run
verify
false
Build Dir: ${project.build.directory} can be omitted to
parse the version of the plugin
. By default, it will go to the core POM to check the version first. If it does not exist, it will go to the central warehouse to check the maven- metadata.xml, to find the latest released version of the plugin to parse.
[size=16px;]The prefix of the plugin[/size]
will check the metadata of the plugin library, which has the prefix of the plugin (under the prefix tag).
If the metadata configuration file under the groupid of each plugin does not contain a prefix, an error will be reported.
[size=20px;] Summary [/size]
The main content is the life cycle and plug-ins, and the query of the prefix of the plug-in needs to be further understood.