Component Tools maven----Simple learning of coordinates, dependencies, warehouses, life cycles

This article makes a brief introduction to some of the more important conceptual coordinates, dependencies, warehouses, and lifecycles in maven.

1. About MAVEN coordinates

The elements of MAVEN coordinates that distinguish any of the MAVEN world's components include GroupID, Artifactid, version, packaging, and classifier, as long as we provide the correct coordinates to access the corresponding artifacts.

<groupId>Org.springframework</groupId>//The actual project under the current MAVEN project, which may have many sub-projects broken down by function, Spring-core, spring-context, etc.<Artifactid>Spring-core</Artifactid>//Current project name<version>4.2.2.RELEASE</version>//Project version<Packaging>Jar</Packaging> How to package//maven projects

2. About Reliance

Dependencies should be the most commonly used in pom.xml files, and used to bring third-party artifacts into the current project.

1 <Project>2   ...3   <Dependencies>4     <Dependency>5       <groupId>Org.srpingframework</groupId>6       <Artifactid>spring-core</Artifactid>7       <version>1.0</version>//above these three tags determine the dependent coordinates to find the component8       <Scope>Compile</Scoperange of >/dependencies9       <Optional>True</Optional>//Flag dependent whether optionalTen       <Exclusions>//exclusion of transitive dependencies One          <exclusion> A          ... -          </exclusion> -       <Exclusions> the     </Dependency> -   </Dependencies> - </Project>

Dependency range: Used to control the relationship of the introduced dependency component to three classpath (compile, test, run), which is divided into five types

Compile: Compile-dependent scopes, which are valid for compiling, testing, and running, use this dependency when this dependency is required in all three cases, spring-core.

Test: Tests the dependencies, which are valid only at test time, which is not valid when compiling the main code or runtime, and the most common example is junit.

Provided: The dependency scope has been provided, the compile test is valid, the run is invalid, the typical example is SERVLET-API, because the Tomcat container already provides SERVLET-API when running, so it is no longer necessary to provide it again.

Runtime: Run-time dependent, test run valid

System: The range of systems, the relationship between Classpath and provided is exactly the same, but the dependency is not from Maven, but from the local introduction, generally not recommended.

Import

Transitive dependency: A-->b-->c,a relies on b,b for C, then because the intermediate dependency of B is also dependent on C.

Dependency Adjustment: When we introduce two or more of the same dependencies at the same time, there is no doubt that the problem arises, so Maven determines the dependency of the introduced version according to the following two laws

The shortest circuit strength Dependent: a-->b-->c-->x (1), a-->d-->x (2), in which case the X (2) is introduced and the X (1) dependency is discarded.

When the dependent road strength is equal, the dependency is determined according to the successive position of the dependency, and the precedence of the order is resolved.

Optional dependencies: For example, Project a relies on project B, and b relies on X or y,b is a persistent Layer isolation toolkit, supports multiple databases, relies on MySQL or Oracle, and needs their drivers when building a project, but relies on only one of them when using it, which requires optional dependencies. An optional dependency is not passed, meaning that x or Y does not have any effect on a.

Exclude dependencies: When we need to exclude this dependency and introduce another dependency, such as Sun JTA Api,hibernate relies on this jar, but because of copyright reasons, the library does not exist in the central warehouse, and Apache has a corresponding implementation, This time, we can eliminate Sun's dependency and introduce the corresponding dependency of Apache.

<exclusions> statement to exclude the dependent GroupID Artifactid here does not need version because Maven's pom file cannot exist GroupID Artifactid the same and
Version has different dependencies, so you just need to groupid Artifactid to determine which dependencies to exclude

Collation dependency:

Suppose there are a lot of dependencies on the spring framework in a project org.springframework:spring-core:2.5.6, org.springframework:spring-bean:2.5.6,
org.springframework:spring-context:2.5.6, they are all different modules from a project, assuming we want to upgrade the srping framework, it's best to extract version,
Convenient for unified modification, similar to the role of constants in Java, here to use <properties>.

<Properties>    <springframework.version>2.5.6</springframework.version></Properties><Dependencies>    <Dependency>        <groupId>Org.springframework</groupId>        <Artifactid>Spring-core</Artifactid>        <version>${springframework.version}</version>    </Dependency></Dependencies>

3. Warehouse

Category: A, remote warehouse B, local warehouse (B1: Central Warehouse, B2: Local Area Network, B3: other public warehouses)

When Maven looks for a widget based on coordinates, it first looks at the local repository, and if it does exist, it will go to the remote repository and download it to the local repository if it is used directly.

<Project>    ...    <repositories>      <Repository>        <ID>Jboss</ID>        <name>JBoss Repository</name>        <URL>http://repository.jboss.com/maven2/</URL>        <releases>//Whether the release widget is allowed to download<enabled>True</enabled>        </releases>      </Repository>      <Snapshots>//Whether to allow download of the snapshot version widget<enabled>False</enabled>      <Updatepolicy>Daily</Updatepolicy>      <Checksumpolicy>Ignore</Checksumpolicy>    </Snapshots>      <Layout>Default</Layout>         </repositories>    ...  </Project>

Snapshot version: A B project is developed at the same time, the B project relies on a project, and when a project changes, it can release a snapshot version for the B project to use its newest features, and Maven will automatically check the latest snapshot of a from the warehouse.

Mirroring: If warehouse X can provide all the content stored in warehouse y, then you can assume that warehouse x is a mirror of Y. Used in conjunction with a common use.

<Mirrors>    <Mirror>          <ID>Mirrorid</ID>          <mirrorof>Repositoryid</mirrorof>          <name>Human readable Name for this Mirror.</name>          <URL>Http://my.repository.com/repo/path</URL>    </Mirror></Mirrors>

4. Life cycle

Maven is divided into three life cycles, namely clean, default, site
Clean: Cleanup Project
Default: Build Project
Site: Establish Project site
Each life cycle contains a number of stages, and the subsequent phases depend on the previous phase, and if a stage in a life cycle is executed, the previous phases of the phase are executed.
The default stage contains the following stages
Validate
Initialize
...
Process-sources: Working with Project resource files Src/main/resources
Compile: Compiling project Master code
...
Test: Testing the Code
...
Package
...
Install
Deploy: Copy the project to the remote repository for use by other developers and MAVEN projects
It should be clear why the main code of the project was compiled after executing the MVN test command.

Executing a MAVEN task from the command line is essentially invoking the life cycle phase of MAVEN, where each life cycle is independent of each other.
MVN clean Install: This command invokes the clean phase of the clean cycle and the install phase of the default cycle, which is performed before the two stages in the same life cycle.

Component Tools maven----Simple learning of coordinates, dependencies, warehouses, life cycles