メイヴン 変更されたもののみを収集します

複数モジュールのMavenプロジェクトで作業する場合、多くの場合、複数の関連モジュールを同時に変更する必要があります。 また、影響を受けるモジュールのみをビルドする場合、残念ながらmavenは自動化されたものを提供しません。 少しグーグルで検索すると、stackoverflowで簡単な1行のソリューションを見つけることができます。

mvn install -amd -pl $(svn st | colrm 1 8 | sed 's /.* ' | xargs echo | sed 's- -,:-g' | sed 's ^ : ')
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これで終わりかもしれません。 しかし、私はもっと欲しかった-より具体的に、どのようにこれを達成したか。

bash、mvn、またはsvnが初めての場合は、スクリプトの簡単な説明：

1. 主な部分はmvn install -amd -pl project_listです。 Mavenのチーム、 project_listおよびその依存関係からプロジェクトを収集します
2. $(...)
   
   
   
   内にあるのは、svnでローカルの変更を取得し、これらの変更からプロジェクト名を取得することです

なぜそれが必要ですか

次の簡単なシナリオを検討してください。

1. モジュールAのParentableインターフェイスに新しいメソッドを追加します
2. このメソッドは、モジュールBのChild（Parentableを実装）クラスに実装します

アセンブリを確認するには、A、Bを個別にアセンブルする必要があります。Childの実装のみが変更された場合、Bのみを再構築するだけで十分です。ただし、メソッドのシグネチャが変更された場合は、両方のモジュールを再度収集する必要があります。

この種の作業では、「プロジェクトBのアセンブリは重要ですか？」 2〜3個のプロジェクトがある場合は便利ですが、さらにプロジェクトがあり、IDEを介したリファクタリングも使用されている場合、アセンブリの関連性がなくなる瞬間を見逃すことは非常に簡単です。

上記のスクリプトの何が問題になっていますか

上記のスクリプトはこの問題を不器用に解決します。常にAとBを収集します。これは時間の面ではあまり効果的ではありませんが、比較的安全です。 あなたは何かを集めることを忘れないでしょう。 私はこのアプローチを約1か月使用しましたが、この余分な時間を費やすよりも収集することを忘れた方が良いと判断しました。

この問題に加えて、このスクリプトが機能しない場合、Maven機能に関連する他の多くの問題があります。 以下で説明します。

何が行われた

このスクリプトのアイデアを基礎として、ファイル（この場合はやすり）で修正しました。 目標は、変更したがまだ収集していないすべてのものを収集するスクリプトを取得することでした。 そしてそれ以上。

bashでスクリプトを変更することは、いくつかの理由でありがたい仕事です。 したがって、開発はpythonで行われました。 プロから：

1. クロスプラットフォーム
2. モジュール性
3. ほぼすべてのLinuxユーザーと多くのウィンドウユーザーが使用しています。
4. シンプルさ

もちろん、私はそれを取得して使用したいだけなので、標準ライブラリだけが依存関係にあります。

それでは、この記事の主要部分から始めましょう-直面しなければならない問題と、使用された解決策の説明です。

何ができますか

自分でできる限り少なくするために、mavenから絞り出すことができる最大値を把握しておくと便利です。 最大値はそれほど大きくありません。 次の領域は、Mavenで収集できます。

1. 1つのプロジェクト
2. 1つのプロジェクトとそのすべてのモジュール（再帰的に）
3. 1つのプロジェクト内のモジュールのリスト。

オプション3は最も適切に見え、導入bashスクリプトで使用されます。 利点のうち、このオプションを使用する場合、パラメーターを指定できます。

• -amd（依存関係も作成）-mavenはすべての依存モジュールも収集します
• -am（またmake）-リストが依存するモジュール

ローカルアセンブリの場合、これらのオプションはあまり役に立ちません。 依存関係アセンブリ（amd）をCIに割り当てることができ、さらに、IDEはMavenを構築せずにコンパイルエラーを示すことができます。

また、親プロジェクト（-am）の構築は冗長です。なぜなら、 変更されていないプロジェクトをMavenリポジトリからプルできます。

残念ながら、これでmavenが役立つことはありません。 公平には、特別なサードパーティのプラグインが含まれていると言う価値があります。 インクリメンタルですが、この場合は、すでに存在するもので作業する必要があり、プロジェクト内で何も変更できません。

問題1：実際の変更のみを収集する

変更内容を理解するには、バージョン管理システムでファイルのステータスを使用するのが最も便利です。 ただし、VCSはこれらの変更がいつ行われたか、アセンブリに含まれているかどうかについては何も知らせません。 それでも、VCSのすべての変更点のリストは、当社のアクティブなプロジェクトであり、さらなる分析の出発点です。

変更がアセンブリとどのように一致するかを調べるために、ファイルが変更された日付と最後のビルドの日付（target / artifact_id-version.jar）を比較します。

最初の近似値としては良いのですが、考慮しなければならないニュアンスがあります。

1. VCSから他の変更が来た場合、プロジェクトを再度組み立てる必要があります
2. target / artifact_id-version.jarがデフォルト値です。 完全に異なる場合があります
3. 変更されたファイルは、アセンブリに関連しない場合があります（たとえば、IDEのプロジェクトファイル）。

ポイント1は、ローカルで変更されたファイルだけでなく、アクティブなプロジェクト内のすべてのファイルも分析することで解決できます。

他の2つの問題は、pomファイルから必要な情報を取得し、アセンブリ中にそれを考慮するだけで解決されます。

問題2：ロールバックの変更

変更があり、アーティファクトを収集した場合、これらの変更をロールバックするときに、アーティファクトを再構築する必要があります。 ただし、VCSのステータスは、このようなファイルに関する情報を提供しません。 したがって、この情報を自分で保存する価値があります。 これを行うには、現在の変更されたプロジェクトを分析した後、この情報をどこかに保存し、次のビルドで現在の変更と保存されたファイルの前の変更を結合します。

問題3：メインプロジェクトに含まれていないモジュール

Mavenプロジェクトの正しい構造は、各プロジェクトが親プロジェクトのモジュールとして記述されているものです。 つまり ルートでmvn installを実行したら、 すべての内部プロジェクトを使用する必要があります。

すべてが正しければ、すべてがよりシンプルになります。 しかし、これは常にそうではありません。 この場合、アンタイドプロジェクトがあります。 これは正しいMavenには適さず、そのようなプロジェクトを-plでスリップすると、彼はあなたにエラーを吐き出します。 -plは、親プロジェクトのサブモジュールとしてリストされているプロジェクトでのみ機能します。

問題を解決するには、そのようなプロジェクトを個別に収集する必要があります。 つまり Mavenは、関連のないルートプロジェクトと同じ回数だけ起動されます。

物事を複雑にするために、これらのプロジェクトが相互接続されると状況が依然として発生する可能性があるため、特定の順序でそれらを収集する必要があります。

問題4：ローカルMavenリポジトリの同期

Mavenは常にローカルリポジトリのアーティファクトに基づいてビルドを行います。 定期的に、ローカルリポジトリを同期し、グローバルリポジトリから更新をダウンロードできます。

そのため、変更を収集し、ファイルを変更しなくなったときに状況が発生する可能性があります。 ただし、遅かれ早かれ、ローカルアセンブリは外部の変更によって置き換えられます。 1つの解決策は、ターゲットファイルではなくローカルリポジトリで変更の日付をチェックすることです。 そして、それらが異なる場合は、新しいビルドを作成する必要があります。

ただし、ターゲットですでに収集されたファイルは正しいままであり、だれもそこから追い出すことはありません。 また、二重の作業を行わないために、完全なアセンブリを実行する代わりに、ローカルリポジトリに単純にドロップすることができます。

問題5：詳細なMaven

これはまったく問題ではありませんが、個人的には、mavenが非常に多くのログを発行する理由は常に疑問です。 座って瞑想しない限り、走っているラインを見ます。 しかし、すべてがうまくいけば、これらのログはまったく面白くありません。 すべてがうまくいかなかった場合、ログは本当に役立ちます。 この原則により、ログを取得します。

純粋な出力に対する素晴らしいボーナスとして、ビルド速度が大幅に向上します。 IOは最も安価な操作にはほど遠いです。

問題6：遅いMaven対速い回避策

上記の問題の多くは、追加情報がMavenから受信された場合により簡単に解決できます。 しかし、彼は非常に遅く、コマンドを非常に長い時間実行します。 それらをループで使用することは、強力なパフォーマンスオーバーヘッドを追加する確実な方法です。

したがって、すべての問題は、その能力と能力を最大限に活用して独自に解決され、Mavenはアセンブリ自体を開始するために一度だけ使用されます。

ただし、Mavenをバイパスする試みはすべて完了しているわけではなく、多くの追加要因を考慮していない場合があります。 プロジェクトの現在の構成についてはそれらで十分ですが、それ以上の高度な構成は考慮されません。

ボーナス1：ビルドサーバーのスクリプト

上記のすべては、自分で変更を加える際にローカルアセンブリのために記述され、使用されました。

しかし、成功した使用経験の後、このアプローチは継続的インテグレーションサーバーで使用でき、リビジョン間で変更されたもののみを収集できると判断しました。 もちろん、ローカルアセンブリについて説明した問題のほとんどを考慮する必要があります。 そのため、両方のバージョンのスクリプトが密接に関連しています。

このようなインクリメンタルアセンブリは、完全なアセンブリとまったく同じ結果になることが重要です。 これは、上記の同じmaven -amdパラメーターを使用して簡単に実現できます。 つまり 変更および/または不快感が収集されます。

受け取ったゲインに関して-私たちの場合、インクリメンタルアセンブリの平均時間は10分の1です。

TeamCityでは、このような機会はすぐに利用できます。 竹にはありません。 他のCIについて知らない

ボーナス2：Pythonプロジェクトミニ縮小器

このセクションは、mavenやjavaとは関係ありません。Python開発者のみが関心を持っている可能性があります。

ここで説明しているスクリプトは、いくつかのモジュールを持つプロジェクトとして記述されています。 コードを操作する方が簡単です。

しかし、複数のファイルを含むスクリプトを共有することはあまり便利ではありません。

または、スクリプトから単一のバイナリをビルドして発行することもできます。 しかし、この場合、その場で修正し、そこで起こっていることを理解する可能性は失われます。

そのため、別のスクリプトが速攻で記述されており、入力としてpythonファイルを受け取り、それとすべての依存モジュールを折りたたみます。 出力は単一のファイルです。 同時に、不要な空の行が削除されます。

エピローグ

ここで説明しているスクリプトは、私と同僚によって1年間使用されています。 CIのスクリプトは現在テスト操作中です。

スクリプトのパフォーマンスはかなり許容範囲です。プロジェクト内での分析と最適化（つまり、1秒未満）に気付きません。

これまでのところ、これはsvnでのみ動作します。 他のVCSで収集する必要はありません。 ただし、オプションで、他のユーザーを簡単に追加できます。 VCSの利点はそれほど必要ではありません。

→ プロジェクトへのリンク

私のアプローチとスクリプトが、他の誰かがmavenを使用して構築する時間と労力を節約できるようになれば、私は非常に幸せになります。

質問、訂正、追加は大歓迎です。