maven日記(四):ライフサイクルとプラグイン
5131 ワード
mavenのライフサイクルは抽象的であり、これはライフサイクル自体が実際の仕事をしないことを意味し、mavenの設計では、実際のタスク(ソースコードのコンパイルなど)はプラグインに任せて完了します.この設計思想は設計モードにおけるテンプレート法と非常に類似している.
public abstract class AbstractBuild {
public void build() {
initialize();
compile();
test();
packagee();
integrationTest();
deploy();
}
protected abstract void initialize();
protected abstract void compile();
protected abstract void test();
protected abstract void packagee();
protected abstract void integrationTest();
protected abstract void deploy();
}mavenのライフサイクルでは、各ステップは1つ以上のプラグイン動作をバインドすることができ、mavenはほとんどの構築ステップにデフォルトのプラグインを記述し、バインドします.たとえばコンパイル用のプラグインにはmaven-compiler-plugin,テストにはmaven-surefire-pluginなどがある.
>>3つのライフサイクルの詳細
初心者はmavenのライフサイクルが全体だと思っていることが多いが、そうではない.mavenはclean、default、siteの3つの独立したライフサイクルを持っている.cleanアップグレードサイクルの目的はプロジェクトのクリーンアップであり、defaultライフサイクルの目的はコンポーネントプロジェクトであり、siteライフサイクルの目的はプロジェクトサイトの構築である.
各ライフサイクルには、順序があり、後のフェーズが前のフェーズに依存するフェーズphaseが含まれます.
3つのライフサイクルは互いに独立しています.例えば、defaultライフサイクルのcompileフェーズをユーザーが呼び出すと、cleanは実行されません.私が何を言うか知っています.
>>cleanライフサイクル:
*pre-clean:クリーンアップを実行する前に完了する必要がある作業
*clean前回構築したファイルのクリーンアップ
*post-clean:クリーンアップ後の作業
>>defaultライフサイクル:
* validate
* initialize
* generate-sources
*process-sources:プロジェクトのプライマリリソースファイルを処理します.一般的に/src/main/resources/ディレクトリの内容を変数に置き換えるなどして、出力ディレクトリのメインclasspathにコピーします
* generate-resources
* process-resources
*compile:プロジェクトのメインソースコードを出力ディレクトリにコンパイル
* process-classes
* generate-test-sources
*process-test-sourcess:プロジェクトテストリソースファイルを処理します.一般的には/src/test/resourcesディレクトリの内容を変数に置き換えるなどして、プロジェクト出力のテストclasspathにコピーします
* generate-test-resources
* process-test-resources
*test-compile:プロジェクトのテストコードをコンパイルします.一般的には、/src/test/javaディレクトリのjavaファイルを出力するテストclasspathディレクトリにコンパイルします.
* process-test-classes
*test:ユニットテストフレームワークを使用してテストを行います.テストコードはパッケージ化されて配置されません.
* prepare-package
*package:コンパイルされたコードを受け入れ、jarなどのパブリッシュ可能なフォーマットにパッケージ化
* pre-integration-test
* integration-test
* post-integration-test
* verify
*install:パッケージをmavenローカルウェアハウスにインストールし、ローカルの他のmavenプロジェクトで使用できます.
*deploy:最終的なパッケージをリモート・ウェアハウスにコピーし、他の開発者やmavenプロジェクトで使用できます.
ここでは、いくつかの段階に重点を置いて説明し、他の公式ドキュメントを参照することができます.
http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html
>>siteライフサイクル
siteライフサイクルの目的は、pomに含まれる情報に基づいて、チームがプロジェクト情報を交流し、公開するのに便利な友好的なサイトを自動的に生成することです.ライフサイクルには次の段階があります.
*pre-site:プロジェクトサイトを生成する前に完了する必要がある作業を実行します.
*site:プロジェクトサイトの生成
*post-site:プロジェクトサイトの生成後に完了する作業を実行
*site-deploy:生成されたプロジェクトサイトをサーバにパブリッシュ
>>コマンドラインとライフサイクル
コマンドラインからmavenタスクを実行する最も主要な方法は、mavenのライフサイクルフェーズを呼び出すことです.
mvn clean:cleanライフサイクルを呼び出すcleanフェーズ、実際にはpre-cleanフェーズとcleanフェーズ
mvn test:defaultライフサイクルを実行するtestフェーズ、すなわちvalidateからtestフェーズ
mvn clean install:cleanライフサイクルをcleanフェーズに実行し、defaultライフサイクルをinstallフェーズに実行します.
mvn clean deploy site-deploy:説明しません..
>>カスタムバインド
組み込みバインディングに加えて、ユーザーは、プロジェクトのソースソースソースソースソースソースのjarパッケージを作成するなど、プラグインターゲットをライフサイクルのある段階に自分でバインディングすることもできます.
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-source-plugin</artifactId>
<version>2.1.1</version>
<executions>
<execution>
<id>attache-sources</id>
<phase>verify</phase>
<goals>
<goal>jar-no-fork</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>プラグインのウェアハウス構成:
<pluginRepositories>
<pluginRepository>
<id>central</id>
<name>Maven Plugin Repository</name>
<url>http://repo1.maven.org/maven2/</url>
<layout>default</layout>
<snapshots>
<enabled>false</enabled>
</snapshots>
<releases>
<updatePolicy>never</updatePolicy>
</releases>
</pluginRepository>
</pluginRepositories>私のブログはすでに引っ越して、新しい住所は:http://yidao620c.github.io/です