3

私は、共通のコードの共有を強調して、共通のソースリポジトリを使用してエンタープライズで動作するために最も適切なビルドシステムを選択しようとしています。ソース階層を次のようにしたいと思います。

--src
   -java
     - 一般
       -ネット
       -データベース
     --team1
     --team2
     --team3
       --lib
 -テスト
   -java
     - 一般
       -ネット
       -データベース
     --team1
     --team2
     --team3
       --lib

目標は、team[1-3]が依存関係を明示的に指定する独立したビルドを持つことができるビルドシステムを持つことです。依存関係は次のようになります。

--team1
   -common / net
   --team3 / lib
 --team2
   -共通/データベース
 --team3

したがって、たとえば、team1のビルドには、team1、common / net、およびteam3/lib内のすべてが含まれます。しかし、他には何もありません。理想的には、テストは同じ方法で統合されます（team1のテストでは、team1、common / net、およびteam3 / libのテストが実行されます）。

私は現在Antを使用していますが、このような階層を管理するための適切な方法を見つけていません。依存関係の階層を管理する機能についてMaven2を調べ始めましたが、モジュールごとに本格的なプロジェクトが必要なようです。それは問題ではありませんが、従来のJavaパッケージ階層にうまくマップされないディレクトリ構造に私を強制するようです。別のレイアウトを使用してビルダーでやりたいことができるかもしれないようですが、それがもろいことがわかるかもしれないのではないかと心配しています。

誰かが私のために働くかもしれない何かを推薦できますか？

4

6 に答える 6

2

ここには実際に3つの問題があると思います。

  • アーティファクトが意味を成すようにプロジェクトをレイアウトする方法。
  • 各プロジェクトのこれらの成果物の共有を最適に処理する方法。
  • 開発チームが新しいプロジェクト構造を使用するように変換しながら、生産性の低下に対処する方法。

最初の問題については、可能な限り Maven 規則を使用し、プロジェクトを複数の成果物に編成するようにしてください。アーティファクトを親の下にネストする必要がある場合は、ネストしてください。依存関係のない最も単純なアーティファクトから始めて、コードを順を追って進めてください。

レイアウトが従来の Java 階層をサポートしないと考える理由がわかりません。特に親ポンムを使用している場合は、うまくいくはずです。

明らかに、最初の問題をどのように処理するかによって、2 番目の問題はかなりの数になる可能性があります。作成するアーティファクトを減らすのではなく増やして、Nexus や Artifactory などのリポジトリ マネージャーを使用してそれらを管理する方が間違っています。少なくともそのようにして、チームのビルドは、リポジトリにアクセスして作業中の jar の最新の SNAPSHOT または RELEASE をプルダウンすることにより、ビルド済みでテスト済みの jar に依存できます。

3 つ目は、Maven をサポートする IDE を使用していることを確認してください。Rational Application Developer 7.0.x や Eclipse 3.4 より前のバージョンに基づく IDE などの使用に行き詰まっている場合、M2Eclipse プラグインを使用することはできません。M2Eclipse がなければ、開発者は理想的ではないいくつかの手動のフープをジャンプする必要があります。Netbeans 6.7 および 6.8 は、非常に優れた Maven サポートを備えています。

于 2009-12-14T19:07:59.393 に答える
0

私は現在Antを使用していますが、このような階層を管理するための適切な方法を見つけていません。

Ant（+ Ivy？）はあなたが望むすべての柔軟性を与えるので、これは驚くべきことです。

依存関係の階層を管理する機能についてMaven2を調べ始めましたが、モジュールごとに本格的なプロジェクトが必要なようです。

これがpom.xmlモジュールごとに1つを意味する場合、それは正しいです。

それは問題ではありませんが、従来のJavaパッケージ階層にうまくマップされないディレクトリ構造に私を強制するようです。

はい、Mavenにはいくつかの規則があり、プロジェクトのディレクトリ構造もその1つです。これは（少し）構成可能ですが、（テストとソースを別々の階層に）必要なレイアウトに一致させることはできないと思います。実際、Mavenを使用する場合は、デフォルトを使用することを強くお勧めします。その哲学を採用する必要があります。これにより、多くの、本当に多くの苦痛を軽減できます（一部のプラグインがハードコードでこれらのデフォルトを使用する可能性があることは言うまでもありません）。仕方）。

正直なところ、従来のJavaパッケージ階層にうまく対応していないディレクトリ構造の意味がよくわかりません。まず、MavenはJavaに最適なので、これは私には意味がありません。第二に、これはより主観的かもしれませんが、あなたのレイアウト（テストとソースツリーが分離されている）は、私にはまったく伝統的に見えません。たぶん、あなたはあなたが伝統的なものによって正確に何を意味するのかを明確にするべきです...

別のレイアウトを使用してビルダーでやりたいことができるかもしれないようですが、それがもろくなるのではないかと心配しています

私はビルダーを本当によく知らないので、それについて多くを言うことはできませんが、それは確かにもっと柔軟であることを知っています。そうは言っても、Antが柔軟性の点であなたに満足を与えないのなら、なぜビルダーが優れているのかわかりません。

また、ビルダーとAnt+IvyのコミュニティはMavenに比べてはるかに小さいことを忘れないでください。これを過小評価しないでください、これは本当の懸念になるかもしれません。

個人的には、Mavenに行き、レイアウトを再検討します。しかし、私が偏見を持っているとしましょう。

于 2009-12-14T08:53:22.683 に答える
0

依存関係階層を管理する機能について Maven 2 を調べ始めましたが、モジュールごとに本格的なプロジェクトが必要なようです。

それはそれを行う1つの方法です。別の方法として、マルチモジュール Maven プロジェクトを次のように編成することもできます。

project
    module-1
        src
            main
                ....
            test
                ....
        pom.xml
    module-2
        src
            main
                ....
            test
                ....
        pom.xml
    ...
    pom.xml

各 pom.xml は、他のツリーによって定義されたモジュールを参照することもできます。ところで、Eclipse Maven プラグインは、このアプローチと、より一般的なプロジェクトごとに 1 つのモジュールのアプローチをサポートしています。

于 2009-12-14T09:34:03.080 に答える
0

あなたが言うように、Maven 2 はあなたのケースに適したオプションです。Maven のフォルダー構造は狂ったものではありません。ですが、後悔なくフォローできる良い仕組みだと思います。

リポジトリ マネージャーを使用すると、一部の依存関係を使用するユーザーが、依存するプロジェクトを必ずしもチェックアウトする必要がなくなります。

于 2009-12-14T07:28:49.930 に答える
0

Buildrでできます。あなたはそれでしばらく生きることができます。

もちろん、スレッドのほとんどの人と同様に、このアプローチはお勧めしません。base_dir を使用して、プロジェクトのベース ディレクトリを変更することもできます。

于 2010-08-01T11:58:21.197 に答える
0

あなたがしようとしているのは、長期的には多くの問題を引き起こすことです...各スタンドアロンコンポーネントは、実際には独自のリポジトリを持つ独自のプロジェクトにする必要があります。そうしないと、1 つの変更で多くの問題が発生する可能性があります。コンポーネントが他のコンポーネントを破壊し、更新に非常に時間がかかります。各コンポーネントを独自のプロジェクトにし、Maven2 を使用してビルドすることを強くお勧めします。

于 2009-12-14T17:09:26.780 に答える