私達について
1Cでは、
1C： C ++および
JavaScriptの エンタープライズプラットフォームだけでなく、Javaアプリケーション、特にEclipseとメッセンジャープラットフォームと密接に統合されたサーバーである
対話システムの新しい開発環境である
エンタープライズ開発ツールも開発しています 。
エントリー
ほとんどの場合、Javaアプリケーションをアセンブルするためのシステムとしてmavenを使用します。この短い記事では、開発プロセス中に対処しなければならない問題の1つと、この問題を克服するためのアプローチについて説明します。
背景とワークフロー
Mavenプロジェクトの開発の仕様により、多くのモジュール、依存関係、および子プロジェクトを使用します。 1つのツリー内のPOMファイルの数は、数十または数百にもなります。
一見作成され、忘れられても大丈夫です。 すべてのファイルを一度に変更または追加する必要がある場合は、エディターとIDEに便利なツールがたくさんあります。 そして、pom.xmlの最も一般的な定期的な変更は何ですか？ プロジェクトのバージョンと依存関係を変更すると信じています。 誰かがこれについて議論したいかもしれませんが、これは私たちの場合です。 その理由は、カーネルと共に、独自のライブラリの多くを同時に開発しており、アセンブリとテスト結果の一定の再現性のために、スナップショットの使用は便利なアプローチではないと思われるためです。 このため、各アセンブリでプロジェクトのバージョン番号を上げる必要があります。
また、開発者はときどきライブラリのブランチを収集し、すべての依存関係に対してパフォーマンスを確認する必要があります。すべての依存関係は、手動でバージョンを変更する必要があります。
初期決定
このような頻繁かつ複数のバージョン変更により、CIはプロセスを簡素化および自動化することを望んでいます。 ここでは、便利な有名な
バージョン、maven-pluginプラグインが助けになります-プラグインして実行します
mvn -Nバージョン：set -DnewVersion = 2.0.1そして、Mavenは必要に応じてすべてを実行します。階層を上から下に実行し、すべてのバージョンを置き換えます-美！ プルリクエストを上げるのは今のままで、同僚は変更を監視し、トランクにすばやく参加できます。 早く？ どんなに。 レビューごとに数百の
pom.xmlがあり、それはコードをカウントしていません。 さらに、このような多数の変更されたファイルとのマージの競合に対して安全な人はいません。 CIプロセス中に、バージョンの変更は機能の変更とともに自動的に発生し、何らかの形で個別に発生するわけではないことに注意してください。
新機能
バージョン3.5.0-beta-1から
Maven Apache Projectのメンバーがバージョン（プレースホルダー）のいわゆる「プレースホルダー」のサポートを開始するまで、しばらくの間、落ち着いて平和に暮らしました。 これらの代替の本質は、プロジェクトのバージョンを具体的に示す代わりに、変数
$ {revision} 、
$ {sha1}および
$ {changelist}が
pom.xmlで使用されることです。 これらのプロパティ自体の値は、<
プロパティ >要素で設定されるか、システムプロパティを介して定義できます
mvn -Drevision = 2.0.0クリーンパッケージシステムプロパティ値は、<
プロパティ >で定義された値よりも優先されます。
親
<プロジェクト>
<modelVersion> 4.0.0 </ modelVersion>
<親>
<groupId> org.apache </ groupId>
<artifactId> apache </ artifactId>
<バージョン> 18 </バージョン>
</ parent>
<groupId> org.apache.maven.ci </ groupId>
<artifactId> ci-parent </ artifactId>
<name>最初のCIフレンドリー</ name>
<version> $ {revision} $ {sha1} $ {changelist} </ version>
...
<プロパティ>
<revision> 1.3.1 </ revision>
< changelist > -SNAPSHOT </ changelist >
<sha1 />
</ properties>
</ project>
子孫
<プロジェクト>
<modelVersion> 4.0.0 </ modelVersion>
<親>
<groupId> org.apache.maven.ci </ groupId>
<artifactId> ci-parent </ artifactId>
<version> $ {revision} $ {sha1} $ {changelist} </ version>
</ parent>
<groupId> org.apache.maven.ci </ groupId>
<artifactId> ci-child </ artifactId>
...
</ project>
バージョン2.0.0-SNAPSHOTをビルドする場合は、次を使用します。
mvn -Drevision = 2.0.0クリーンパッケージリリースしたい場合は、スナップショットをゼロにするだけです
mvn -Dchangelist =クリーンパッケージ*上記の例は、Maven Apache Project Webサイトの
記事から
引用したものです。
厳しい現実
すべてが健康で健康です。満足感を味わう時が来ましたが、そうではありません。
$ {revision}はリポジトリで公開されたアーティファクトの説明の値に置き換えられず、mavenはそれが何であるかを理解しないため、インストールとデプロイではこのメソッドは機能しません。
<親>
<groupId> org.apache </ groupId>
<artifactId> apache </ artifactId>
<version> $ {revision} </ version>
</ parent>
トンネルの終わりの光
問題の解決策を探さなければなりません。 この状況は
flatten-maven-pluginによって保存できたかもしれません。 このプラグインはpomのすべての変数を許可しますが、同時に、アセンブリ中にのみ必要であり、公開されたアーティファクトを他のプロジェクトにインポートする場合には必要ない他の情報を大量に切り取ります。 また、プラグインはすべての親子の依存関係を「まっすぐに」し、その結果、必要なものがすべて含まれたフラットなPOMを取得します。 不便なのは、彼が「多すぎる」を切り過ぎたことで、それは私たちにはまったく合わなかった。 このプラグインの開発に関する情報を調べた結果、私たちだけが宇宙にいるわけではないことが判明し、2018年8月に、pom.xmlを「損なう」方法を独自に決定できるようにするために、プラグインリポジトリのgithubでプルリクエストが作成されました。 開発者は苦しんでいる人の声に耳を傾け、すでに12月に新しいバージョン1.1.0のリリースで、新しいresolveCiFriendliesOnlyモードがflatten-maven-pluginに登場しました。これは、これまでとは異なり、pom.xmlをそのままにして、
<version>要素を除き、
$を許可します
{revision} 、
$ {sha1}および
$ {changelist} 。
プロジェクトにプラグインを追加する
<プラグイン>
<プラグイン>
<groupId> org.codehaus.mojo </ groupId>
<artifactId> flatten-maven-plugin </ artifactId>
<バージョン> 1.1.0 </バージョン>
<構成>
<updatePomFile> true </ updatePomFile>
<flattenMode> resolveCiFriendliesOnly </ flattenMode>
</構成>
<実行>
<実行>
<id>平坦化</ id>
<phase>プロセスリソース</ phase>
<目標>
<goal>平坦化</ goal>
</ goals>
</実行>
<実行>
<id> flatten.clean </ id>
<phase> clean </ phase>
<目標>
<goal> clean </ goal>
</ goals>
</実行>
</ executions>
</ plugin>
</ plugins>
できた！
ハッピーエンド
これからは、プロジェクト全体のバージョンを変更し、すべての依存関係にそれを知らせるために、ただ1つのルート
pom.xmlで<
revision >要素を編集する必要があります。 レビューに反映されるのと同じ変更が加えられたこれらのファイルは100つか2つではなく、1つです。 さて、
versions-maven-pluginを使用する必要はありません。