7

優れたスケーラブルなソリューションが見つからない問題：

特定のアーティファクトの複数のフレーバーを提供するプロジェクトがあります。これはマルチモジュールプロジェクトとして設定されており、現在3つのモジュールがあります。

  • / flavour1_module
  • / flavour2_module
  • / flavour3_module

問題は、同じ方法でセットアップする必要がある別の50のプロジェクトがあるということです。つまり、3つのフレーバーを提供します。

検討したソリューション：

  1. すでに作成されたマルチモジュールプロジェクトを他のすべての50プロジェクトの親に変える
    • 短所：それはうまくいきません。親のモジュールで保持されている命令は継承されないため、実行されません。
  2. maven-archetype-pluginを使用してマルチモジュールプロジェクトテンプレートを作成し、テンプレートに基づいて50個すべてのプロジェクトを作成します
    • 短所： flavour4が必要な場合は、50個のプロジェクトすべてを手動で更新してflavour4_moduleを追加する（そしてそのコンテンツを複製する）必要があります。スケーラブルではありません。
  3. すべてのフレーバーの構成を単一のpomに埋め込み、プロファイルに基づいてそれらを有効または無効にします（つまり、モジュールを介した継承ではなく、プロファイルによる構成を使用します）。次に、50のプロジェクトを親としてそのプロジェクトに向けます。これにより、「インライン」モジュールが作成されます
    • 短所：モジュールによって提供される独自のメカニズムをそのまま実装する必要があります。（たとえば、すべてのフレーバーを個別のディレクトリに構築します）。また、モジュールが提供する明確な分離も失われます。

それをうまく行う方法はありますか？他に選択肢はありますか？

ありがとう、Lukasz

編集：

もう1つのオプションは、maven-reactor-pluginをreactor：inject-modulesゴールで拡張することです。これにより、外部アーティファクトからモジュール定義がダウンロードされ、その定義が通常のモジュールとしてアタッチされます。これにより、その場で新しいモジュールが作成されます。次に、50のプロジェクトすべてがこのpom.xmlを親にすることができます。

構成は次のようになります（ドラフト）：

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-reactor-plugin</artifactId>
  <version>1.0</version>
  <executions>
    <execution>
      <id>inject</id>
      <phase>initialize</phase>
      <goals>
        <goal>inject-modules</goal>
      </goals>
      <configuration>
        <modules>
          <module>
            <artifactId>flavour1_module</artifactId>
            <groupId>[ groupId ]</groupId>
            <version>[ version ]</version>
          </module>
          <module>
            <artifactId>flavour2_module</artifactId>
            <groupId>[ groupId ]</groupId>
            <version>[ version ]</version>
          </module>
          <module>
            <artifactId>flavour3_module</artifactId>
            <groupId>[ groupId ]</groupId>
            <version>[ version ]</version>
          </module>
        </modules>
      </configuration>
    </execution>
  </executions>
</plugin>

このように行くのは理にかなっていますか？

アップデート：

実行するモジュールのリストを操作するプラグイン（上記で説明したモジュールインジェクションのアイデア）を作成することは、モジュールがMavenコアによって処理され、メカニズムが拡張されるように設計されていないため、実装できないようです。プラグイン。これは、同様の仕事をする両方のプラグイン、つまり実行するプロジェクトのリストを操作するという事実によって確認されます。

システムコールを実行してMaven子プロセスを作成することでトリックを実行します。それは非常に不安定な解決策であるため、私にとってはそれは進むべき道ではありません。実際、maven-reactor-pluginはMaven3と互換性がなくなりました。

maven-invoker-pluginはまだ有望に見えます。プラグインは元々統合テストを実行するように設計されていましたが、コンパイルフェーズなどを拡張するために使用することも可能です。ただし、子pom.xml-sをリソースとして扱い、その場で変更する必要があります。ここで説明した問題の場合、解決策は複雑すぎて不安定になります。Mavenモデルを構築している間、メモリ内で動作できるより軽いものが好きです。

そのため、今のところ、プロファイルを使用して、可能な限りコンパクトにしようとしています。おそらくしばらくすると、問題についてもう一度考える必要があります。

4

4 に答える 4

1

これで、maven-tilesプラグインを使用して目的の動作を得ることができます。

Maven タイルを使用すると、さまざまな poms でビルド動作を定義し、好きな場所にインポートできます。

MNG-5102に動作サンプルが添付されています--> daddy3.zip

Maven の継承のみの Strait Jacket が正式に削除されました。

于 2012-10-02T20:14:42.133 に答える
0

私の意見では、このために複数の異なるアセンブリ記述子を作成し、実行ごとに異なる記述子を参照する複数のプラグイン実行を構成できます。マルチモジュールプロジェクトではなく、シングルモジュールとしてプロジェクトを維持する必要があります。ディストリビューションに同じクラスのセットが含まれているが、リソースまたはライブラリが異なる場合は、機能する可能性があります。

        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-assembly-plugin</artifactId>
            <version>2.2.1</version>
            <executions>
                <execution>
                    <goals>
                        <goal>single</goal>
                    </goals>
                    <id>assembly</id>
                    <phase>package</phase>
                    <configuration>
                        <descriptors>
                                <descriptor>one.xml</descriptor>
                        </descriptors>
                    </configuration>
                </execution>
                <execution>
                    <goals>
                        <goal>single</goal>
                    </goals>
                    <id>assembly</id>
                    <phase>package</phase>
                    <configuration>
                        <descriptors>
                                <descriptor>two.xml</descriptor>
                        </descriptors>
                    </configuration>
                </execution>
                <execution>
                    <goals>
                        <goal>single</goal>
                    </goals>
                    <id>assembly</id>
                    <phase>package</phase>
                    <configuration>
                        <descriptors>
                                                      <descriptor>three.xml</descriptor>
                        </descriptors>
                    </configuration>
                </execution>
            </executions>
        </plugin>

そこにアセンブリプルーを構成して親pomを作成し、そこから配布の数とパッケージの変更を制御できるようにすることができます。プロジェクトは、さまざまなパッケージの詳細について知る必要はありません。

ネイティブライブラリを個別のモジュールとして保持し、リポジトリメカニズムを使用してコンパイル済みライブラリをインストールすることを強くお勧めします。さまざまな分類子を使用して、次のようなプラットフォームを分離できます。

mylib-2.0.0-win32_x86.dll
mylib-2.0.0-linux_x86.so
mylib-2.0.0-linux_x86_64.so

次に、これらのライブラリをプロジェクトの依存関係として参照し、ディストリビューションと一緒にパッケージ化することができます。

全体的な解決策は、さまざまなディストリビューションがどのように異なるか、およびディストリビューションをパッケージ化する全体的なプロセスに大きく依存しますが、これはうまくいくと思います。

究極のよりスケーラブルなソリューションは、Mavenプラグインを実装して独自のパッケージを作成することです。

于 2012-04-21T13:04:48.483 に答える
0

私の経験では、オプション 3が最も効果的でしたが、必要なようにスケーリングする必要はありませんでした。必要な場合は、maven-ant-plugin を使用してパラメーター化された ant スクリプトを作成しました。カスタマイズ。いくつかの欠点があります。つまり、ant と maven の両方で作業するため、実際の POM を理解するのはより困難ですが、maven で可能であるよりも柔軟性が高くなります。

于 2012-07-07T00:29:56.580 に答える
-1

Maven 3を使用している場合は、親pomのプロファイルを定義し、ファイルの存在に基づいてそれらをアクティブ化できます。子モジュールでは、空のファイルを作成するだけで「フレーバーを継承」できます。

これは、以下のリンクでより適切に文書化されています。

于 2012-08-01T15:14:08.213 に答える