Mavenとのセカンドライフ

大部分のhabrazhitelにとって、大規模なソフトウェア開発の中で、技術や言語が高度なものよりもはるかに遅れていることがよくあるのは、啓示ではないと思います。 残念ながら、これは避けられません。何百万行ものコードを取得して別の言語に書き換えたり、より新しいフレームワークを使用したりすることは、ある時点では不可能だからです。

しかし、ある時点で遅延が非常に大きくなり、製品が競争力を失い、徐々に市場から消えていきます。 私がたまたま観察したのは、このような緩やかな減衰の状況でした。

ここでは、特定のケースで、どうしても避けられないものを遅らせ、Mavenプロジェクトコレクターを使用して開発を活性化しようとした方法についてお話したいと思います。

おそらく、私が開発したシステムの主な利点は、わずかな労力でMavenを使用して任意の言語で実装されたプロジェクトを教えることができ、バージョンを尊重し、プロジェクトのビルド時に自動的に更新される別のパッケージからアセンブルできることです。 必要なのは、ソースをコンパイルできるコマンドラインユーティリティだけです。スクリプト言語の場合、検証ユーティリティが役立ちます。

与えられた：

-「コア」が一連のdllで構成され、ソースのないアプリケーション開発者に提供されるシステム。
-Pascalに似ているが、Pascalの標準機能（すべてではない）に加えて、適用されたプログラミング言語を使用すると、dllの「コア」に実装されたオブジェクトを使用できます。 このアプリケーション言語は、一種のコードバイトにコンパイルされ、別の「コア」dllによって実行されます。

したがって、主な開発は上記の魔法の応用言語で行われ、その魅力はおそらく尊敬されるコミュニティを恐怖に陥れる可能性があり、「コア」は定期的に（数か月に1回の新しいバージョン）本社から配信され、変更できません。

Pascalに似た、Delphiに基づいて作成された独自のプログラミング言語を開発および保守することは、おそらく悪い考えである可能性が非常に高いですが、15〜17年前にこのことを考え始めた人はいませんでした。 他の目標を追求しましたが、一般的には成功しました。

システム自体は、サーバー、クライアント、およびシンクライアントを備えた顧客に販売される製品です。 当然、ほとんどの顧客はシステムの標準機能に満足していないため、システムをニーズに合わせて「仕上げる」応用開発部門がいくつかあります。 各プロジェクトは、プログラマーの個別のグループに従事しています。 グループ間の相互作用と経験の交換は、壊滅的に小さいです。 したがって、各グループは車輪を再発明し、同じレーキを10回目にする機会を得ます。

分析後、この部門間の相互作用の欠如は、主に共通コードを使用するメカニズムの欠如によることが明らかになりました。 つまり、グループ間で経験とソースコードの交換があった場合、ライブラリ（ソース）は別のプロジェクト（別のクライアントの製品）にコピーされ、その時点で存在していたすべての不具合と欠点を保持して独立した生活を送り始めましたコピー。

この状況を改善するために、一連の共有コードライブラリ（ パッケージ ）を使用して、リポジトリ（リポジトリ）とプロジェクトコレクションシステムを編成することが決定されました。

デフォルトで同様の機能を実行し、柔軟なライフサイクルとプラグインシステムの大きな柔軟性を備えているため、Mavenがこのツールとして選択されました。

しかし、まず最初に

主な問題は、調査の始めに私も疑わなかったが、パッケージにはバイトコードにコンパイルされていないファイル、つまりソースを含める必要があるということでした。 コンパイルは、使用される「カーネル」のバージョンの下で正確に行われる必要があります。 簡単にするために、アプリケーションのソースをbpaと呼びます。 これは、Mavenの標準LCとは若干異なります。

そのような啓示の後、ソースからパッケージを作成することが決定されましたが、作成中にアトミックなコンパイルをチェックする必要があります。 言い換えると、.classが最初にコンパイルされたときにほぼ標準のMavenライフサイクルを使用し、次にリソースとともにjarにパッケージ化されます。 私の場合に限り、コンパイルされたファイルの代わりに、パッケージは圧縮されたソースbpaから形成されました。

Mavenの仕組みについて少し

Mavenのライフサイクルは完全に完了しており、一連のフェーズでは、必要なプロジェクトアセンブリのほぼすべての段階が考慮されます。

そして、LCのあるフェーズ、たとえば「mvn compile」を開始しようとしている間に、実際には検証（プロジェクト検証）からコンパイルまでのフェーズチェーン全体を実行します。 一部のフェーズでは、pom.xml（Mavenプロジェクトのメインファイル）にはヘッダーのみがあり、プラグインの起動を示す単一の表示ではないにもかかわらず、呼び出されるいわゆるデフォルトプラグインがあります。

Mavenは完全なプラグインシステムであることを別に言及する価値があります。 言い換えれば、彼はプラグインを起動する以外にほとんど何もできませんが、彼らはすでに驚くほど多くの方法を知っています。 Mavenにプロジェクトアセンブリの特性を教えたい場合は、pom.xmlに適切なプラグインを適切なフェーズで適切なパラメーターで起動するための指示を追加する必要があります。

このような完全に有効な空のpom.xmlは、空であるにもかかわらず、mvn deployコマンドを受信すると、src / mainフォルダーからJava Plug-inの初期化、コンパイル、パッケージ化、およびデプロイを起動します。

<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.mycompany.projectgroup</groupId> <artifactId>projectname</artifactId> <version>01.03.03-00</version> <build> </build> </project> 

Mavenの主な使用ポリシーは、すべてのアクションにデフォルトのパラメーターがあり、これらのデフォルトが十分でないか、著しく違反している場合にのみ追加の設定が必要であることです。 私の場合、非常に多くのデフォルトを放棄しなければならなかったため、pom.xmlはそれほど控えめに見えなくなりました。

pom.xmlで新しいライフサイクルを構築する

パッケージを実装するために、次のライフサイクルが選択されました。

初期化 （初期化）-設定（プロパティまたはキー=値）ファイルから設定を読み取り、プロパティタグに追加します。 プロパティタグについては後ほど説明します。
generate-sources （ソースコード生成）-zipからこのパッケージ/プロジェクトの依存関係であるすべてのパッケージをダウンロードし、現在のパッケージ/プロジェクトのソースとともにさらにコンパイルするために別のディレクトリに解凍します。
compile -bpasのコンパイルプラグインを実行します。これにより、正しいコンパイル順序が決定され、言語のコマンドラインコンパイラが起動します。 以下に自分のプラグインについて簡単に説明しますが、それを書くためのガイドをこの記事の範囲外に移動することをお勧めします。
アセンブリ -ソースファイルのサブディレクトリの構造を保持しながら、bpasソースで構成されるパッケージをzipでパックします。
デプロイ （この場合、リポジトリへのアンロード）-アセンブリフェーズで収集されたアセンブリzipは、pom.xmlおよびその他のパッケージ情報が追加されたローカルMavenリポジトリに送信されます。 この手順は、通常のデプロイjarファイルとほぼ同じですが、特別なパラメーターがあります。

clean-このフェーズは、アセンブリフェーズの一般的なLCには含まれていませんが、多少異なりますが、アップグレードされているため、言及する価値もあります。 コンパイルされたファイルがあるディレクトリの標準的な削除に加えて。 （targetDirectory）、依存パッケージのダウンロードおよびアンパック中に生成されたガベージを削除する必要がありました。

pom.xmlの一般的な構造

pom.xmlを条件付きで、ヘッダーとアセンブリの2つの部分に分割します。

ヘッダーは、パッケージID（groupId、artifactId、バージョン）、プロパティ（内部定数として機能するプロパティ）、ローカルリポジトリ（distributionManagement）、ローカルプラグインリポジトリ（pluginRepositories）、ローカルパッケージリポジトリ（リポジトリ）、および依存関係です。このパッケージ（依存関係）。 同時に、3つのリポジトリはすべて同じリポジトリを指すことができますが、基本的にこれらは3つの異なるエンティティであり、それぞれ個別に指定する必要があります。 たとえば、プラグインを他のコードとは別に保存し、httpアクセスを使用してリポジトリ内のパッケージにアクセスし、ファイルリポジトリのようにそこに「デプロイ」することを決定できます。

アセンブリ（ビルドタグ）はpom.xmlの2番目の部分であり、デフォルト設定以外のさまざまなプラグインによるライフサイクルのこのフェーズまたはそのフェーズの処理機能が構成されます。 さらに、プロジェクトのアセンブリに参加するディレクトリとパラメーターがそこに構成されます。
sourceDirectory-コンパイルのソースが置かれているディレクトリ。
finalName-アーカイブに圧縮した後の最終ファイル名。
directory-コンパイルされたファイルが配置される作業ディレクトリ。
さらに、これらすべてのパラメーターにはデフォルト値があり、これらのデフォルトとは異なる必要があるため、ここでの個別の指示が必要であることをもう一度思い出したいと思います。

ビルドタグでのライフサイクル実装

ここで、定義したLCに戻り、必要な構成で目的のプラグインを呼び出して、ライフサイクルの各フェーズがどのように実装されるかを見てみましょう。

初期化する

繰り返しますが、プロパティタグについて少し説明します。 それがなぜ必要で、どのように使用されるかを説明しましょう。

非常に無礼な言い方をすれば、このタグはプログラム（pom.xml）で使用される定数の宣言に似ています。 しかし、3つの異なる方法で値を取得できます。 また、各メソッドには、本当に必要なときに結果がどうなるかを決定する優先順位があります。

最も低い優先順位は、次のように、プロパティを直接プロパティタグに書き込むことです。

  <properties> <helloText>Hello my friend</ helloText > </properties> 

「mvn –DhelloText = Hi initialize」のように、Mavenの起動時に直接優先順位が高くなります
Mavenがこのパラメーターで起動すると、helloTextタグの初期値は、現在のセッションの起動ラインで渡された値、つまり xmlでは保存されません。 そのような定数がまったく存在しなかった場合、このセッションでは存在し、使用できます。 存在しないすべての定数の値は空の文字列です。

現在のセッションのプラグインによって、proprtiesタグに値を追加することが最も優先されます。 また、pom.xmlには保存されません。 「name = value」を含むプロパティファイルに個々のアセンブリ設定を行うために使用するのは、このメカニズムです
これを行うには、properties-maven-pluginプラグインを使用します

  <build> … <plugins> … <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>properties-maven-plugin</artifactId> <version>1.0-alpha-1</version> <executions> <execution> <id>1</id> <phase>initialize</phase> <goals> <goal>read-project-properties</goal> </goals> <configuration> <files> <file>..\build.conf</file> </files> </configuration> </execution> <execution> <id>2</id> <phase>pre-clean</phase> <goals> <goal>read-project-properties</goal> </goals> <configuration> <files> <file>..\build.conf</file> </files> </configuration> </execution> </executions> </plugin> … </plugins> 

状況依存の設定を別のファイルに入れるための興味深いソリューションに加えて、ライフサイクルのまったく異なるフェーズで同じプラグインがどのように実行されるかについての良いデモンストレーションがあります。 これは<executions />タグによって保証されます。このタグでは、必要なフェーズごとに個別の<execution />タグが作成されます。 <execution />タグには一意のIDを含める必要があり（実行が複数の場合）、他のすべてよりも優先度が高い個別の構成タグを含めることもできます。

生成ソース

ソース生成の段階で、リポジトリから再帰的にダウンロードし、必要なすべてのパッケージを解凍します。これは依存関係に示されています。 繰り返しますが、実際には自分で何もする必要はありません。 プラグインは、適切な設定を示した後、すべてを行います。

  <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-assembly-plugin</artifactId> <version>2.2.1</version> <executions> <execution> <id>unpackSources</id> <phase>generate-sources</phase> <goals> <goal>unpack</goal> </goals> </execution> </executions> <configuration> <workDirectory>${packagesPath}</workDirectory> </configuration> </plugin> 

$ {packagesPath}の構築は、タグ「/ project / properties / packagesPath」から値を取得する必要があることを意味します。

それとは別に、アンパックにmaven-assembly-pluginプラグインを使用することは非推奨と見なされ、Maven 3での使用は推奨されないことに注意してください。代わりに、上記と同様の設定でmaven-dependency-pluginを使用します。 古いバージョンのプラグインを使用して、範囲内のいくつかのタスクを実行するために同じプラグインがどのように構成されているかをもう一度示します。

コンパイルする

コンパイルの段階を何度も調整する必要がありましたが、独自のコンパイルプラグインを作成することで主な困難が生じました。 独自のMavenプラグインを作成するための段階的な手順は別の記事のトピックであるため、ここではこれに焦点を当てません。 最終的に、ここで紹介する資料はスクリプト言語に使用できます。スクリプト言語のコンパイルはまったく必要ありません。
1つ確かなことは、どんなに頑張っても、ネイティブmaven-compile-pluginの起動を無効にできないことです。その呼び出しは、Javaソースをコンパイルすることです（superPom.xmlの編集の可能性を考慮せずに）。 したがって、私のコンパイルプラグインの設定は次のとおりです。

  <plugin> <groupId>com.companyname.utils</groupId> <artifactId>BPASCompilerPlugin</artifactId> <version>0.1.0.2</version> <executions> <execution> <phase>compile</phase> <goals> <goal>bpascompile</goal> </goals> </execution> </executions> <configuration> <protectionServer>${protectionServerName}</protectionServer> <protectionAlias>${protectionServerAlias}</protectionAlias> <bpasccPath>${pathToBPASCC}</bpasccPath> <binaryVersion>${env.BINARY_VERSION}</binaryVersion> </configuration> </plugin> 

使用されるパラメーター：
protectionServer-保護サーバー。これがないと、コマンドラインコンパイラを起動できません。
protectionAlias-保護サーバーの使用済みライセンスのセクション。
bpasccPath-コマンドラインコンパイラへのフルパスまたは相対パス。
binaryVersion-コンパイルされたライブラリに「マウント」されるバージョン。

これはプラグインのすべての設定ではありませんが、私が言ったように、これは別の大きな記事のトピックです。 原則として、構成セクションはまったく省略でき、プラグインに必要なすべてのパラメーターは、Mavenの基本概念に対応するデフォルト値でプラグインによって初期化されます。

集会

アセンブリフェーズを渡すと、Mavenはデフォルトでmaven-assembly-pluginを実行するように構成され、ビルドタグでアセンブリフェーズでの起動を明示的に示し、その設定をオーバーライドして動作させることができます。 コンパイルする前にパッケージを解凍するために同じプラグインを使用したので、今度は、このプラグインの設定の完全版を提供します。これには、パックと解凍の両方が含まれます。

  <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-assembly-plugin</artifactId> <version>2.2.1</version> <executions> <execution> <id>unpackSources</id> <phase>generate-sources</phase> <goals> <goal>unpack</goal> </goals> </execution> <execution> <id>packSources</id> <phase>assembly</phase> <goals> <goal>assembly</goal> </goals> </execution> </executions> <configuration> <descriptors> <descriptor>..\src.xml</descriptor> </descriptors> <workDirectory>${packagesPath}</workDirectory> </configuration> </plugin> 

id = packSourcesの2番目の実行セクションと、このフェーズに必要な設定.. \ src.xmlが表示されます。 Src.xmlには、ソースをパッケージ化する方法の設定が含まれています。 実際、これらの設定はすべて記述子タグに直接配置できますが、これはpom.xmlで非常に乱雑になる可能性があります。
これは、図を完成させるためのsrc.xmlの例です。

 <?xml version="1.0" encoding="UTF-8"?> <!-- standart pack settings for bpas package--> <assembly> <id>src</id> <formats> <format>zip</format> </formats> <fileSets> <fileSet> <includes> <include>pom.xml</include> </includes> </fileSet> <fileSet> <directory>SOURCE</directory> <excludes> <exclude>.svn</exclude> <exclude>**/*${packagesDirName}*/**</exclude> </excludes> </fileSet> </fileSets> </assembly> 

packagesDirNameは、/ project / properties pom.xmlファイルの定数です
それとは別に、パッケージ設定を別のファイルに転送することで、すべてのパッケージに対して1つのパッケージ構成を作成できたことは非常に便利です。

配備する

このプラグインの設定を指定したかどうかに関係なく、デプロイフェーズもMavenによって起動されます。 それらを再定義することで、このプラグインを私たち自身のために機能させました。

  <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-deploy-plugin</artifactId> <version>2.5</version> <configuration> <file>${project.build.directory}\${project.artifactId}-src.zip</file> <url>${project.distributionManagement.repository.url}</url> <repositoryId>${project.distributionManagement.repository.id}</repositoryId> <groupId>${project.groupId}</groupId> <artifactId>${project.artifactId}</artifactId> <version>${project.version}</version> <packaging>zip</packaging> <pomFile>pom.xml</pomFile> </configuration> </plugin> 

このような手動設定では、 maven-deploy-pluginにより、任意のファイル（またはファイルのグループ）を有効なライブラリ（パッケージ）としてMavenリポジトリにアップロードできます。 次に、設定を順番に分析してみましょう。
file-パッケージとしてMavenリポジトリに送信されるファイル。
url -Mavenリポジトリへのパス
repositoryId-デプロイが実行されるリポジトリの識別子。
groupId 、 artifactId 、 version -Mavenリポジトリの標準パッケージID。 ライブラリを一意に識別できるのは、これら3つのパラメーターです。 パッケージング-デプロイメント機能には、リポジトリに送信されるファイルのパックも含まれます。したがって、パッケージで何もしないように、zipを再度指定する必要があります。そうしないと、jarのようにアンパックおよびパックされます。
pomFile-このパラメーターを指定すると、pom.xmlとして指定したファイルがパッケージに追加されます;元の名前は異なる場合があります。 オリジナルのpom.xmlを維持することは多くの理由で有益であるため、この機能を軽視しません。

きれいに

先に述べたように、クリーンフェーズは標準LCの一部ではありません。 最初のタスクは、mvn cleanコマンドの実行後、プロジェクトに重要なアクティビティの痕跡が残らないことです。 この場合、標準のtargetSourceフォルダー（ビルドタグで示される）に加えて、パッケージ/プロジェクトのコンパイルを正常に行うために、依存関係として「マージ」されたすべてのパッケージを削除する必要があります。

したがって、設定：

  <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-clean-plugin</artifactId> <version>2.4.1</version> <configuration> <filesets> <fileset> <directory>${packagesPath}</directory> </fileset> </filesets> </configuration> </plugin> 

ディレクトリ -削除される実際のディレクトリ。 ここで、プラグインの作成者は一般に受け入れられている概念から離れており、プラグイン設定を明示的に指定しても、デフォルトのアクションはキャンセルされないことに注意してください。 しかし、この場合、これは不必要な設定から私たちを救うので、非常に良いです。

最初に個々の設定ブランチを処理することがどれほど難しいかを念頭に置いて、以下のパッケージのいずれかのフルテキスト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.companyname.packages</groupId> <artifactId>String</artifactId> <version>0.1.0.1</version> <name>String</name> <url>http://maven.apache.org</url> <properties> <project.build.sourceEncoding>windows-1251</project.build.sourceEncoding> <packagesPath>${basedir}/SOURCE/${packagesDirName}</packagesPath> </properties> <distributionManagement> <repository> <id>spb-maven-repo</id> <name>spb-maven-repo</name> <url>file://\\SPB-FS\maven-repo</url> </repository> </distributionManagement> <pluginRepositories> <pluginRepository> <id>spb-maven-repo</id> <name>spb-maven-repo</name> <releases> <enabled>true</enabled> <updatePolicy>always</updatePolicy> <checksumPolicy>fail</checksumPolicy> </releases> <snapshots> <enabled>true</enabled> <updatePolicy>always</updatePolicy> <checksumPolicy>fail</checksumPolicy> </snapshots> <url>http://spb-maven-repo</url> <layout>default</layout> </pluginRepository> </pluginRepositories> <repositories> <repository> <id>spb-maven-repo</id> <url>http://spb-maven-repo</url> </repository> </repositories> <dependencies> <dependency> <groupId>com.companyname.packages</groupId> <artifactId>Arithm</artifactId> <version>0.1.0.1</version> <type>zip</type> </dependency> <dependency> <groupId>com.companyname.packages</groupId> <artifactId>bUnit</artifactId> <version>0.9.0.0</version> <type>zip</type> </dependency> </dependencies> <build> <directory>USER</directory> <sourceDirectory>${basedir}/SOURCE</sourceDirectory> <finalName>${project.artifactId}</finalName> <plugins> <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>properties-maven-plugin</artifactId> <version>1.0-alpha-1</version> <executions> <execution> <id>1</id> <phase>initialize</phase> <goals> <goal>read-project-properties</goal> </goals> <configuration> <files> <file>..\build.conf</file> </files> </configuration> </execution> <execution> <id>2</id> <phase>pre-clean</phase> <goals> <goal>read-project-properties</goal> </goals> <configuration> <files> <file>..\build.conf</file> </files> </configuration> </execution> </executions> </plugin> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-assembly-plugin</artifactId> <version>2.2.1</version> <executions> <execution> <id>unpackSources</id> <phase>generate-sources</phase> <goals> <goal>unpack</goal> </goals> </execution> <execution> <id>packSources</id> <phase>assembly</phase> <goals> <goal>assembly</goal> </goals> </execution> </executions> <configuration> <descriptors> <descriptor>..\src.xml</descriptor> </descriptors> <workDirectory>${packagesPath}</workDirectory> </configuration> </plugin> <plugin> <groupId>com.companyname.utils</groupId> <artifactId>CompilerPlugin</artifactId> <version>0.1.0.2</version> <executions> <execution> <phase>compile</phase> <goals> <goal>compile</goal> </goals> </execution> </executions> <configuration> <protectionServer>${protectionServerName}</protectionServer> <protectionAlias>${protectionServerAlias}</protectionAlias> <bpasccPath>${pathToBPASCC}</bpasccPath> <binaryVersion>${env.BINARY_VERSION</binaryVersion> </configuration> </plugin> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-deploy-plugin</artifactId> <version>2.5</version> <configuration> <file>${project.build.directory}\${project.artifactId}-src.zip</file> <url>${project.distributionManagement.repository.url}</url> <repositoryId>${project.distributionManagement.repository.id}</repositoryId> <groupId>${project.groupId}</groupId> <artifactId>${project.artifactId}</artifactId> <version>${project.version}</version> <packaging>zip</packaging> <pomFile>pom.xml</pomFile> </configuration> </plugin> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-clean-plugin</artifactId> <version>2.4.1</version> <configuration> <filesets> <fileset> <directory>${packagesPath}</directory> </fileset> </filesets> </configuration> </plugin> </plugins> </build> </project> 

まとめ

私はすべてをできるだけ詳細に説明しようとしましたが、すべて同じように、舞台裏ではまだ後続の記事で取り上げる予定の膨大な数の質問がありました。

• フェーズと目標は、自身とプラグインとの関係です。
• アーキタイプの作成-pom.xml構成と一連のデフォルトファイルをすばやくデプロイするためのプロジェクトテンプレート。
• Mavenリポジトリとその管理。
• Mavenプラグインを作成およびデバッグする方法。
• 「くしゃみ」ごとに独自のプラグインを作成しない方法。

私自身が自分の仕事に満足しているという事実にもかかわらず、この形式ではプロジェクトをバッチで組み立てるシステムはまだ完全ではありませんが、上記の説明はバッチ/プロジェクトの完全なライフサイクルの実装を十分に示しています。 実際、これは実行可能なフレームワークであり、その上で可能性をほとんど広げることができます。

このようなバッチアセンブリの主な利点は次のとおりです。

• 汎用コードの追加が簡単
• 依存関係の追加とプロジェクトの構築が簡単
• プロジェクトの透明性（使用されているものと非標準の改善の実際の量は明らかです）
• Mavenメカニズムのおかげで、パッケージ間の循環依存関係の識別。
• 一般的なコードの修正の自動配布。
• 通常の開発者/テスターに​​よる使いやすさ（3〜4チームを十分に知っている）。

便利なリンク

使用されるバージョン管理の依存関係
Maven用の最も基本的なプラグインのセットとそれらに関するドキュメント
メインのMavenリポジトリに含まれるプラグインの追加セット