🥕 📂 👾 自転車からMavenへ 👴🏾 😰 😋

つい最近まで、私が収集したJavaで書いたすべてのプロジェクトが収集されました。そして、私は物事のこの整列に非常に満足していました：プロジェクト全体を組み立てた後、すべてがリンクされたすべてのライブラリを含むdistディレクトリにきちんと折り畳まれ、そこにユーザードキュメント、必要なネイティブライブラリ（たとえばFirebirdから）、およびパス、すなわちアーカイブにすべて。手動で行った後、自転車で、そしてMavenで。カットの下には、私がどのようにMavenキャンプに来たのか、そしてその結果についての物語があります。

Java jarのニックネームをexeファイルでラップしたいときに面白いことが起こり始めました。どういうわけかコウモリのニックネームよりも見た方がよかったです（アイコンをねじ込むことができる場合のみ）。コピーされてから、すべてがアーカイブに収集され、次にバージョン番号がアーカイブの名前に含まれるようになり、その後...および...一般に開始されました。これらのウィッシュリストは最終的に自転車を記述し、私の自転車の名前としてプロジェクト名にビルダープレフィックスを追加し、すべての作業を行う小さなコードを記述しました（NetBeansがプロジェクトを構築することは事実です）。そして、ホラーについてのバージョン番号は、一般的にソースのどこかにある文字列定数から引き出されました。もちろん、私のツールは普遍的なふりをしておらず、上記のウィッシュリストは他のプロジェクトでさらに繰り返されることを約束しました。

そして、私はMavenに会いました。あるロシア語のリソースで誤ってそれについて読んだのですが、彼が私の問題を解決することに気づきましたが、彼はそれをなぜ使うのか、なぜバイクがクールではないのかを完全には理解していませんでしたか？私がインターネットでフォーラムを調べたところ、彼らが説明した、説明した、ある種の納得したものと同じ理解できないフォーラムが見つかった。私の英語の知識を考慮に入れて、研究は困難で始まり、すべての文書はその言語で書かれています。 Haberの記事は大いに役立ちました。ApacheMaven- 基本とMaven-プロジェクトアセンブリの自動化。正しい判断を下す最後のストローは、Mercurialリポジトリからクローン化されたJavaプロジェクトのライブラリを再リンクする方法を思い出すことでした。まあ、少なくともそれらはほとんどなく、以前のプロジェクトの開発者は反対に座っていました、尋ねることができます:)。

だから、私の目の前には目標がありました：すべてが美しく行われなければならないので、すべてが私のために行っていました:)そして怠は、彼らが言うように、進歩のエンジンです。その結果、次のタスクが形成されました。

-NetBeans（すべてのライブラリを含む）のようなプロジェクト全体のアセンブリ。

-コードに登る必要のないアセンブリの番号付けの自動化。

-exeファイルでjarをラップ。

-Mercurialリポジトリとの同期（一般に、コミット番号に基づいてアセンブリを作成したかった）。

幸いなことに、NetBeansのMavenサポートはすぐに使用できます。

-ユーザードキュメントとその他の必要なファイル（たとえば、jarアーカイブ外の.propertiesファイル）を追加します。

「NetBeansのような」という概念に含まれるもの：すべてのリソース（イメージ、.propertiesファイル）をコピーし、関連するすべてのライブラリをプルアップし、マニフェストに必要な情報を書き込みます。デフォルトでは、mavenは.classファイルのみを収集し、jarアーカイブにはそれ以上を収集せず、マニフェストはわずかです。

この記事では、プロジェクトのライフサイクルのフェーズについては説明しません。ビルドライフサイクルの概要と上記の記事をご覧ください。

そのため、プロジェクトのアセンブリに関するすべての情報がpom.xmlファイルに格納されていることは、私たち全員（もちろん、私は既に説明しています:)）を知っています。依存関係（プロジェクトとプラグインのアーティファクト）、およびこれらのプラグインの構成、何をどのように行うか、どこに置くか、実行する他の操作があります。各プラグインは、その<plugin />タグで、もちろん、バージョン、名前、ライフサイクルフェーズを示すように構成されています。すべての構成は、プロジェクト全体のビルドを担当する<build />タグ内の共通の<plugins />タグに配置されました。

ポイントを見てみましょう。

NetBeansのようなプロジェクトを構築する

ここに含まれるものは何ですか？ええ、すでに決定しました：srcディレクトリからすべてのリソースをコピーし（ソースがあります）、すべての依存関係をターゲットディレクトリ（ターゲット）にコピーし、マニフェストに情報を追加します。

すべての依存関係のコピーは、設定の下のmaven-dependency-pluginプラグインによって実行されました。

<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-dependency-plugin</artifactId> <configuration> <outputDirectory>${project.build.directory}/lib/</outputDirectory> <overWriteReleases>false</overWriteReleases> <overWriteSnapshots>false</overWriteSnapshots> <overWriteIfNewer>true</overWriteIfNewer> </configuration> <executions> <execution> <id>copy-dependencies</id> <phase>package</phase> <goals> <goal>copy-dependencies</goal> </goals> </execution> </executions> </plugin>

それらはすべて（NetBeansのように）libディレクトリに追加されることに注意してください:)。同時に、ライブラリを新しいバージョンで上書きし、現在のバージョンを上書きせず、最終バージョンなしで依存関係を上書きしないことを示します（スナップショット）。また、操作が進行中のフェーズ（パッケージ）も示します。原則として、ゲストが来ても違いはありません。

マニフェストの情報は次のように追加されました。

 <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-jar-plugin</artifactId> <configuration> <archive> <manifest> <addClasspath>true</addClasspath> <classpathPrefix>lib/</classpathPrefix> <classpathLayoutType>simple</classpathLayoutType> <mainClass>com.khmb.block_v2.Block_v2App</mainClass> </manifest> <manifestEntries> <Version>${buildNumber}</Version> </manifestEntries> </archive> </configuration> </plugin>

<classpathPrefix />タグは、ライブラリがlibディレクトリからプルされていることを示しています。単純な値を持つ<classpathLayoutType />タグは、jar-nicksが1つのヒープでスローされることをコレクターに伝えます。リポジトリの値もあり、ライブラリはmavenリポジトリのように追加されます。パッケージ、バージョン、ライブラリ名の名前を持つすべてのサブディレクトリ。

以下で説明する変数$ {buildNumber}に注目する価値があります。

依存関係に加えて、マニフェストはプログラムの起動元のクラスを示します。

使用されるプラグインのすべてのパラメーターの説明は、 Maven JAR pluginにあります。多くの興味深いことがあります。

次に、jarアーカイブにアセンブルする前に、すべてのリソース（画像および.propertiesファイル）を、コンパイルされた.classファイルのあるディレクトリにドロップする必要がありました。

 <plugin> <artifactId>maven-resources-plugin</artifactId> <version>2.5</version> <executions> <execution> <id>copy-resources</id> <phase>validate</phase> <goals> <goal>copy-resources</goal> </goals> <configuration> <outputDirectory>${project.build.outputDirectory}/com/khmb/${project.name}</outputDirectory> <resources> <resource> <directory>${project.build.sourceDirectory}/com/khmb/${project.name}</directory> <filtering>true</filtering> <includes> <include>**/*.properties</include> </includes> </resource> <resource> <directory>${project.build.sourceDirectory}/com/khmb/${project.name}</directory> <includes> <include>**/*.png</include> </includes> </resource> </resources> </configuration> </execution> </executions> </plugin>

トリッキーなコピーではなく、Mavenにすべてを正確に同じように配置するように依頼してください。ただし、1つの特殊性があります。PNGファイル（およびプロジェクトがこの形式の画像のみを使用する）がそのようにコピーされる場合、.priopertiesファイルはフィルタリング、つまりコピーされます。プラグインはそれらの内部を調べ、mavenの変数で何かを置き換える必要がある場合、それを置き換えます。これは、タグパラメーター<filtering />-trueによって示されます。リソースが異なる<resource />タグに区切られているのはこのためです-写真をフィルターしても意味がありません。

プロジェクトのコンパイルは、次のプラグインによって規制されています。

 <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <version>2.3.2</version> <configuration> <source>${jdkVersion}</source> <target>${jdkVersion}</target> </configuration> </plugin>

変数$ {jdkVersion}については少し後で説明します。

コードに入らずにアセンブリの番号付けを自動化する

そして、これらの.propertiesファイルの中には何がありますか？すべてが非常に単純です。そのうちの1つに、アプリケーションのバージョン番号があります。これは、実行時に拡大し、このアプリケーションに関する情報（いわゆる）とともにウィンドウに表示されます。

 Application.version = ${buildNumber}

そして、このビルド番号はどこから来たのですか？彼はbuildnumber-maven-pluginプラグインのおかげです。プラグインの役割は、絶対に任意のバージョン番号を作成することです。プログラムのバージョン番号（またはアーティファクト）とビルド日付を含めることにしました。

 <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>buildnumber-maven-plugin</artifactId> <version>1.0</version> <configuration> <format>{0}-{1,date,yyyyMMdd}</format> <items> <item>${project.version}</item> <item>timestamp</item> </items> <doCheck>true</doCheck> <doUpdate>true</doUpdate> </configuration> <executions> <execution> <phase>validate</phase> <goals> <goal>create</goal> </goals> </execution> </executions> </plugin>

バージョン番号はいくつかの部分（<format />タグ）から組み立てられ、各部分は中括弧で囲まれ、Java言語のMessageFormatの記述に従って形成されます。各部分には、置換する値を示す<item />タグがあります。ちなみに、「buildNumber」というテキストを挿入できます。アセンブリ中に、プロジェクトディレクトリのルートにこのアセンブリの番号が生成されるたびにのみ（値はbuildNumber.propertiesファイルに保存されます）。私が拒否したのは、プログラムの操作性、何回実行する必要があるかを常にチェックしているため、その数が非常に大きくなる可能性があるためです。

exeファイルでjarをラップする

私の自転車の時代に、私は良いlaunch4jプログラムに出会いました。これは、jarをexeでラップするだけでなく、アプリケーションにアイコンを追加することもできました）、作成者、バージョンなどに関する情報は、どのバージョンのjreを使用するべきか、どこを参照するかを示します（ポータブルバージョンを携帯することができます）が、一般的にはもっと多くのことができます。すべての設定はxmlファイルに保存され、その説明はプログラムのWebサイトにあります。このxmlファイルを自転車で生成し、そのパスをパラメーターとして呼び出されたlaunch4j.exeに渡しました。出力にexeファイルがあり、これは依存関係とそのjarカウンターパートに関連付けられています（つまり、特別なパラメーターが指定されていない限り、同じ依存関係を参照しているはずです）。この便利なプログラムがMavenプラグインとしても存在することは、私の幸せでした。プラグインの構成は、ここで見ることができるいくつかの機能を除いて、その古い兄弟プログラムとほぼ完全に一貫しています。ところで、WindowsだけでなくLinuxでもバイナリを収集できます。以下は私の設定です。

 <plugin> <groupId>com.akathist.maven.plugins.launch4j</groupId> <artifactId>launch4j-maven-plugin</artifactId> <executions> <execution> <id>l4j-clui</id> <phase>package</phase> <goals> <goal>launch4j</goal> </goals> <configuration> <headerType>gui</headerType> <outfile>target/${exeFileName}.exe</outfile> <jar>target/${project.artifactId}-${project.version}.jar</jar> <errTitle>${product.title}</errTitle> <icon>favicon.ico</icon> <classPath> <mainClass>com.khmb.block_v2.Block_v2App</mainClass> <addDependencies>true</addDependencies> <preCp>anything</preCp> </classPath> <jre> <minVersion>${jdkVersion}.0</minVersion> </jre> <versionInfo> <fileVersion>${project.version}.0</fileVersion> <txtFileVersion>${project.version}</txtFileVersion> <fileDescription>       </fileDescription> <copyright>Copyright © 2011 ${product.company}</copyright> <productVersion>${project.version}.0</productVersion> <txtProductVersion>${project.version}</txtProductVersion> <companyName>${product.company}</companyName> <productName>${product.title}</productName> <internalName>${exeFileName}</internalName> <originalFilename>${exeFileName}.exe</originalFilename> </versionInfo> </configuration> </execution> </executions> </plugin>

使用するjreのバージョン（変数$ {jdkVersion}に対応）、入力ファイル、出力ファイル、ねじ込むアイコン、exeファイルに関する情報を表示するときに表示できる情報を示しました。 jreのバージョン番号が$ {jdkVersion} .0のように書かれているのはなぜですか？非常に簡単です。launch4jプラグインにはxxx [_x]形式のバージョン番号が必要です。pom.xmlファイルの他の場所（コンパイルプラグイン構成内）では、xx形式のバージョン番号を指定する必要があります。したがって、一般的な部分は変数に入れられました（最後を参照）。

ところで、プラグインがインターネット上のMavenリポジトリからプルアップするためには（中央リポジトリにそのようなプラグインはありません）、もう1つ指定する必要があります：

 <repositories> <repository> <id>akathist-repository</id> <name>Akathist Repository</name> <url>http://www.9stmaryrd.com/maven</url> </repository> </repositories> <pluginRepositories> <pluginRepository> <id>akathist-repository</id> <name>Akathist Repository</name> <url>http://www.9stmaryrd.com/maven</url> </pluginRepository> </pluginRepositories>

タグ<repositories />および<pluginRepositories />は、プロジェクトのルートタグ内にあります。依存関係記述タグおよびアセンブリ記述タグとともに。

Mercurialリポジトリと同期

最初は、プラグインがアクティブなブランチの最後のコミットの番号を取得し、それをプロジェクトのビルド番号として挿入するというアイデアでした。しかし、これを行う方法はうまくいきませんでした。教えてくれた人たちにはとても感謝しています。

一般に、リポジトリで作業することの本質は、プロジェクト全体を組み立てる前に、リポジトリから最新の変更を確実に受け取ることでした。ここで、maven-scm-pluginプラグインが役に立ちました。さらに、Gitとは異なり、Mercurialの完全なサポートが発表されました。まあ、私は水銀リポジトリに慣れているので、それは素晴らしいです:)。構成は次のとおりです。

 <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-scm-plugin</artifactId> <version>1.5</version> <configuration> <!-- <username>username</username> <password>password</password> //--> <connectiontype>developerConnection</connectiontype> </configuration> <executions> <execution> <phase>validate</phase> <goals> <goal>update</goal> </goals> </execution> </executions> </plugin>

ログインとパスワードのパラメーターは、許可を必要とせずにローカルリポジトリーを使用するため、コメント化されています。はい、ところで、<build />タグの外側では、リポジトリが配置されている場所にパラメーターが示されます。

 <scm> <connection>scm:hg:file:///${project.basedir}</connection> <developerConnection>scm:hg:file:///${project.basedir}</developerConnection> <url>file:///${project.basedir}</url> </scm>

どのように、何を、どこで締めるべきかについては、公式ドキュメントSCM Implementation：Mercurialで再度説明されています。リポジトリに対してリクエストが行われ、最新の変更が受け入れられ、プロジェクトの最新バージョンが取得されます（もちろん、アクティブなブランチのフレームワーク内）。

フィニッシュライン

最終的な線を引き、プロジェクトにユーザーのドキュメントを含め、すべてをアーカイブにまとめて喜ばせることが残っています。 maven-assembly-pluginがこれを担当します。

 <plugin> <artifactId>maven-assembly-plugin</artifactId> <executions> <execution> <id>assembly</id> <phase>package</phase> <goals> <goal>attached</goal> </goals> <configuration> <descriptors> <descriptor>assembly.xml</descriptor> </descriptors> </configuration> </execution> </executions> </plugin>

プラグインのドキュメントでは、添付のターゲットを使用することを強くお勧めします。構成全体は、個別のassembly.xmlファイルに保存されます。その内容は次のとおりです。

 <assembly xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0 http://maven.apache.org/xsd/assembly-1.1.0.xsd"> <id>bin</id> <formats> <format>zip</format> </formats> <fileSets> <fileSet> <directory>${project.basedir}</directory> <outputDirectory>/</outputDirectory> <includes> <include>data.ini</include> <include>ReleaseNotes.txt</include> </includes> </fileSet> <fileSet> <directory>${project.basedir}</directory> <outputDirectory>/docs</outputDirectory> <includes> <include>User's guide.pdf</include> </includes> </fileSet> <fileSet> <directory>${project.build.directory}</directory> <outputDirectory>/</outputDirectory> <includes> <include>${exeFileName}.exe</include> <include>${project.artifactId}-${project.version}.jar</include> <include>lib/**</include> </includes> </fileSet> </fileSets> </assembly>

どのディレクトリからアタッチする必要があるかを示します（exeファイルとリンクライブラリを忘れないでください）。フォーマットのリストでは、zipのみを指定します。残りは原則として私の場合は必要ありません。すべて、出力では、必要なものがすべて入ったアーカイブを取得します（主なことは何も忘れないことです:)）。

変数

すべての構成は、これらの変数でいっぱいです。まあ、教えてください。

-$ {project.basedir}-mavenのプロジェクトルートディレクトリへのパスを保存します。

-$ {project.build.directory}-通常、mavenのプロジェクトのターゲットサブディレクトリに対応します。

-$ {project.build.outputDirectory}-コンパイルされた.classファイルが追加されるターゲット内のディレクトリに対応します。通常、クラスには名前があり、その内容から最終的なjarアーカイブが収集されます。

-$ {project.name}-<artifactId />タグから取得したアーティファクトの名前

-$ {project.version}-アーティファクトバージョン、タグ値<version />

残りの変数は、pom.xmlファイルのルート<project />タグ内の<properties />タグで手動で決定されました。その内容は次のとおりです。

 <properties> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> <exeFileName>block</exeFileName> <product.title> </product.title> <product.company>   :)</product.company> <product.year>2011</product.year> <jdkVersion>1.6</jdkVersion> </properties>

exeファイルの名前は拡張子なしで指定されていることに注意してください、なぜなら launch4jプラグイン構成では、フルネームを指定する必要がある場合があり、拡張子を指定しない場合があります。

おわりに

Mavenを使用してください！ :)時間をかけて勉強することで、後で時間を節約できます。

したがって、私のプロジェクトはローカルのMavenリポジトリにありましたが、その公開をリモートリポジトリ（組織のネットワークなど）で構成できます。 Mercurialリポジトリからプロジェクトを複製すると、すべての依存関係が自動的に強化されます-非常に便利です。そして、少なくともNetBeansで、少なくともEclipseで、少なくともIntelliJ IDEAでプロジェクトをさらに開発します-好きなように。

PS：すべての依存関係はインターネットから取得され、ローカルのMavenリポジトリに追加され、将来はそこから取得されます。仕事中のMavenプロキシ構成がNTLM認証と互換性がないという私の「幸福」は何だったので、多くの依存関係を手動でダウンロードし、必要なサブディレクトリに入れる必要がありました。

自転車からMavenへ