Mavenの研究ノート---のMavenのコアコンセプト

1.合意されたディレクトリ構造

（1）ディレクトリ構造を作成することに合意した
[1]ルートディレクトリ：プロジェクト名
[2] SRCディレクトリ：ソース
[3] pom.xmlファイル：Mavenプロジェクトのコア構成ファイル
[4]メインディレクトリ：メインプログラムを格納する
[5]試験カタログ：testディレクトリを保存する
[6] javaのカタログ：店舗Javaソースファイル
[7]リソースディレクトリ：設定の保存枠や他のツールは、ファイル
の完全なディレクトリ構造は以下の通りである：
ここに画像を挿入説明
（2）なぜ、ディレクトリ構造、それの合意を遵守する必要がありますか？
[1] Mavenは・Mavenのコンパイルを自動化するためには、例えば、コンパイルするには、ビルドに私たちの自動化プロジェクトを担当することには、それはどこのJavaソースファイルを保存する知っている必要があります。
我々は独自のフレームワークやツールのノウハウを作りたいものを、2つの方法がある場合は、[2]：
。構成フレームワークを伝えるための明確な方法

<param-value>classpath:spring-context.xml</param-value>

B。すでに内部に存在する合意を遵守します

規則（3）一般>設定>エンコーディング
のヒント：Mavenのよく使用するコマンドを：

mvn clean  清理
mvn compile  编译主程序
mvn test-compile 编译测试程序
mvn  test    执行测试
mvn package  打包
mvn install  安装
mvn site  生成站点

2.POM

（1）意味：プロジェクトオブジェクトモデルプロジェクトオブジェクトモデルの
アナロジー：DOMを：ドキュメントオブジェクトモデルドキュメントオブジェクトモデル
Mavenプロジェクトのための（2）のpom.xmlは、ビルドプロセスに関連するすべての設定は、このファイルに設定されている、コアの設定ファイルであります動的Webプロジェクトのweb.xmlの同等の役割の重要性。
シンプルなpom.xmlファイル:(以下は、特定のパラメータの内部に導入される）の例

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.gs.maven</groupId>
  <artifactId>WebProject2</artifactId>
  <version>0.0.1-SNAPSHOT</version>
  <packaging>jar</packaging>
</project>

座標3

（1）数学座標：

[1]平面上、X、2つのベクトルのY平面の使用は、一意の任意の点に配置することができる
空間で、[2]、X、Yの使用は、Z 3つのベクトルを一意にのみ空間内の任意の点を決定することができます

（2）Mavenの座標：を使用し、以下の3つのベクトルを一意倉庫に（3つのベクトルのGAVと称する）Mavenプロジェクトを見つけることができる
[1]グループID：逆+プロジェクトの会社または組織のドメイン名

  <groupId>com.gs.maven</groupId>

〔2〕たartifactId：モジュール名

 <artifactId>WebProject2</artifactId>

[3]バージョン：

<version>0.0.1-SNAPSHOT</version>

倉庫経路の座標との対応関係（3）Mavenプロジェクト

<groupId>org.springframework</groupId>  
 <artifactId>spring-core</artifactId>  
<version>4.0.0.RELEASE</version>

リポジトリ内の設定ファイルに対応する上部位置である：ORG / springframework /スプリングコア/ 4.0.0.RELEASE /スプリングコア4.0.0.RELEASE.jar

4.Maven倉庫

（1）倉庫カテゴリ：
[1]ローカルリポジトリ：コンピュータ上のすべての現在のMavenプロジェクトのためのあなたの現在のコンピュータサービスのデプロイするためにDirectoryリポジトリ
[2]リモートリポジトリ：
1）PW：ローカルエリアネットワークの範囲内で、LAN環境で構築すべてのMavenのエンジニアリングサービス。
ここに画像を挿入説明
2）中央倉庫：インターネット上で立てられ、すべてのMavenプロジェクトのための世界的なサービス
3）中央リポジトリミラーリング：ユーザーの倉庫のアクセス速度を向上させるために、トラフィックの中央倉庫を共有するためには、

保存された（2）倉庫の内容：Mavenプロジェクト

[1]のMavenプラグイン自体が必要
[2]ジャーパッケージサードパーティのフレームワークやツール
[3]私たち自身のMavenプロジェクトの開発
（第一の方法JDK、我々自身の第二者）

4.依存（コア部）

（1）Mavenのローカルリポジトリをするとき、依存関係情報に依存するJARパッケージで見つけることが解決します。インストールが倉庫に入ることができた後、私たち自身の発展のためのMavenプロジェクトでは、使用はinstallコマンドをMVN。
（2）レンジ依存性（即ち依存3つの値のpom.xmlタグの範囲内）
の値は、提供、コンパイル、テストしました

ここに画像を挿入説明

依存の（3）配信：
[1]利点：各モジュールの依存関係プロジェクト文では繰り返さない転写必要は、例外に依存するプロジェクトの「底」にすることができる
非送信範囲に依存することができないコンパイル：注記[2] 、各プロジェクトのモジュールので、必要に応じ声明を繰り返す必要があります。
（4）依存負
[1]に依存する場合除外するように設定する必要があります必要に不安定導入ジャーパッケージの転送ので頼らないし
[2] :(依存負のサンプルコードが提供されます）

	<exclusions>
		<exclusion>
				<groupId>commons-logging</groupId>
				<artifactId>commons-logging</artifactId>
		</exclusion>
	</exclusions>

（5）依存の原則：
[1]役割：モジュールプロジェクトとの間の競合を解決するためのJARパッケージ
[2]シナリオは、1をとる：最短パス第一原理ことを確認し
ここに画像を挿入説明
、優先度の同じ最初の宣言へのパス：[3]シナリオは2を想定します
最初の宣言タグの宣言の順序を意味する

（6）統合管理は、バージョンに依存します

[1]この例の場合：あなたは春に依存している場合は統一各ジャーパッケージが行う方法を、4.0.0から4.1.1へのアップグレード？手動で一つ一つを変更することは信頼性がない
[2]推奨構成：
。Aのカスタムラベルの使用統一バージョン番号はタグであります

<properties>
    	<gs.spring.version>4.1.1.RELEASE</gs.spring.version>
</properties>

B。位置で引用された文の$ {name}のカスタムラベルのバージョンを使用して、統一されたバージョンが必要です

<groupId>org.springframework</groupId>  
<artifactId>spring-core</artifactId>  
<version>${gs.spring.version}</version> 
<scope>compile</scope>

[3]実際には、カスタムラベル宣言のデータ構成を持つラベルは、引用した例を使用することができ、統一書が必要な方は、声明のバージョン番号に依存するだけではありません。

5.ライフサイクル/プラグイン/目標

（1）生命周期
【1】各个构建环节执行的顺序：不能打乱顺序，必须按照既定的正确顺序来执行
【2】Maven的核心程序中定义了抽象的生命周期，周期中各个阶段的具体任务都是由插件来完成的。
【3】Maven核心程序为了更好的实现自动化构建，按照这样的特点执行生命周期中的各个阶段，不论现在需要执行生命周期的哪一个阶段，都是从这个生命周期的最初位置开始执行。
(2)插件和目標
【1】生命周期中的各个阶段仅仅定义了要执行的任务是什么
【2】各个阶段和插件的目标是对应的
【3】相似的目标由特定的插件来完成
ここに画像を挿入説明
【4】可以将目标看作“调用插件”功能的命令。

6.继承

（1）场景：由于test范围的依赖不能传递，所以必然分散在各个模块工程中，很容易造成版本不一致（例如不同模块中依赖不同的junit版本）
（2）需求：统一管理各个模块中对junit依赖的版本
（3）解决思路：将junit依赖统一提取到“父”工程中，在子工程中声明junit依赖是不指定版本，以父工程中统一设定为准，同时便于修改。
（4）操作步骤：
【1】创建一个Maven工程作为父工程，注意打包方式为pom
【2】在子工程中声明对父工程的引用
【3】将子工程的坐标与父工程中重复的内容删除
【4】在父工程中统一管理junit的依赖（pom.xml的配置如下）

<!-- 配置依赖的管理 -->
  <dependencyManagement>
		<dependencies>
			<dependency>
				<groupId>junit</groupId>
				<artifactId>junit</artifactId>
				<version>4.9</version>
				<scope>test</scope>
			</dependency>
		</dependencies>
	</dependencyManagement>

【5】在子工程中删除junit依赖的版本号部分

Tips:配置继承后，执行安装命令时要先安装父工程

7.聚合

（1）アクション：キーのインストールは、各モジュールに機能
設定モジュールは、（一般的に親プロジェクトを使用するために使用）全重合にプロジェクトの重合に関与する：（2）の構成

<!-- 配置聚合 -->
  <modules>
  		<!-- 指定子工程的相对路径 -->
  		<module>../Hello</module>
  		<module>../HelloFriend</module>
  		<module>../MakeFriend</module>
  </modules>

（3）の方法：集計プロジェクトのpom.xmlを右 - ----> MVNインストールとして>ファイル名を指定して実行

CGS_SX

公開された19元の記事・ウォンの賞賛2 ・ビュー409

プライベートの手紙の懸念