問題タブ [dependency-management]

本番プロジェクトでサードパーティのライブラリ/コンポーネントを使用する場合、そのライブラリのリリース済みバージョンのみを使用することに厳格ですか?

ライブラリのプレリリース版またはベータ版の使用を検討するのはいつですか?

ライブラリのバグや欠点に遭遇し、すでにそれを使用することにコミットしている場合、ライブラリにパッチを適用するか、コードで回避策を作成しますか?

Javaビルドシステムでパッケージの依存関係に制限を課す可能性は何ですか? たとえば、クラスはパッケージmyapp.server.bl.Customerを参照できません。myapp.client.ui.customlayoutAnt ベースまたは IDE 固有のソリューションに興味があります。

(カスタム) パッケージの依存関係規則に違反し、ビルドが中止されたことを示すエラー メッセージをビルドで取得したいと考えています。また、Ant スクリプトや IDE プロジェクト ファイルの外部で、できればテキスト ファイルで依存関係をリストに維持したいと考えています。

(私はMavenを知りませんが、モジュールの依存関係管理のサポートが向上していることをここで読みました)

javaメインクラスのすべてのクラス依存関係を見つける方法はありますか?

メインクラスのインポートとそのインポートを手動でふるいにかけましたが、同じパッケージにあるクラスをインポートする必要がないため、不完全なリストをまとめていたことに気付きました。

依存関係を再帰的に (おそらく定義された深さまで) 見つけるものが必要です。

Maven2 の隠れた機能は何ですか?

多くの場合、新しいプロジェクトを開始するときは、コードベースをどのように構築するかという点で最善と思われるものから始めます。1 つのことをうまく実行し、コードベースの他の部分から分離され、他の (類似の) プロジェクトで自分自身が再利用したり、他の人が利用できるようにオープン ソース化したりする可能性のある多数の小さなモジュールのアイデアが気に入っています。

しかし、私が実際に何かを本番環境に持ち込もうとしている危機的な週になると、これらのさまざまなモジュールをすべて管理する複雑さがオーバーヘッドを大きくしすぎることが何度かありました (適切なドキュメントとデプロイ方法にもかかわらず)。当時、私は単純に方針を変更し、すべてのモジュールを 1 つのリポジトリにバンドルして、すべてを 1 つのコードベースとして管理していました。つまり、さまざまなブランチを通じてすべてを一緒に追跡し、ステージング環境やテスト環境にデプロイすることができます。

これらのさまざまなアプローチの長所と短所は何ですか。また、いずれかの方法で作業を管理するにはどうすればよいですか?

1 つのモノリシック コードベースの利点:

• 展開が簡単
• ロールバックしやすい
• すべての変更をまとめて簡単に分岐/管理
• 文書化および管理する潜在的に複雑な依存関係がない (または少ない)

モジュール依存関係の利点:

• 再利用性
• クリーンなアーキテクチャ (1 つのモジュールが 1 つのことをうまく行う)

前回のプロジェクトでは、MSBuild をスクリプト言語として使用しました。(ええ、本当に!) また、C# でより意味のある部分のために、何百ものカスタム MSBuild タスクを作成しました。(MSBuild タスクのボイラープレート コードを生成する MSBuild タスクも作成しました。はい、それ自体を消費しました。)

他の人がこの同じアプローチを取ることはお勧めしませんが、私が非常に役立つと思ったものの 1 つは、組み込みの依存関係管理です。ご想像のとおり、依存関係を表現するのは簡単で、MSBuild に依存関係を満たすように任せることができました。たとえば、ソフトウェアのほぼすべてのステップで、特定のファイル セットを特定の場所にコピーする必要がありました。あなたは簡単に書くことができます：

を実行するStep2と、ファイルが一度だけコピーされます。

依存関係ツリーを構築して満たすことは、ソフトウェアではかなり一般的です。MSBuild チームが依存関係管理コードを取得し、MSBuild から分離して、誰もが使用できる .NET Framework に移動してくれることを願っています。それをむき出しにして、この方法で依存関係を管理するための最良のオプションは何だと思いますか?

私のプロジェクトの多くには、Castle/NHibernate/Rhino-Tools スタックが含まれています。これについて紛らわしいのは、Castle がいくつかの NHibernate ライブラリに依存し、NHibernate がいくつかの Castle ライブラリに依存し、Rhino-Tools が両方に依存していることです。

3 つのプロジェクトすべてを自分のマシンでビルドしましたが、NHibernate と Castle のビルドから得られたライブラリを使用して Rhino-Tools をビルドしたので、NHibernate/Castle ライブラリをコピーするのは少し冗長だと感じています。

現在、プロジェクト ツリーの / thirdparty/libs フォルダー内の個別のフォルダーにすべてのプロジェクトを含めています。プロジェクトに / thirdparty/libs/rhino-tools を配置して、そこから Castle/NHibernate ライブラリを使用するだけでよいのでしょうか? ファイルを複製しないことは理にかなっているように思えますが、各プロジェクトを個別のフォルダーに配置することも好きです。

これについてどう思いますか。

独自の ant ビルド ファイルをすべて用意したいモジュールがたくさんあります。ただし、モジュールには他のモジュールへの依存関係があります。ビルド ファイル間の依存関係を定義する最良の方法は何ですか?

<import>、<ant>、および <antcall> タスクを見てきましたが、これを行うためのより良い方法があるようです。

ivysettings.xml ファイルに次のものが含まれている場合:

そして私のivy.xmlファイルには以下が含まれています：

Ivy を実行したときから、これはhttp://repository.springsource.com/ivy/bundles/external/org.junit/com.springsource.org.junit/4.4.0/com.springsource に解決されることがわかります。 org.junit-sources-4.4.0.jar

したがって、解決策は次のとおりです。

Ivy が URL パターンの [組織]、[モジュール]、および [リビジョン] をどのように解決するかはわかりますが (当然)、[アーティファクト] と [拡張] をどのように解決しますか?

URL リゾルバに関するドキュメントが不足しているようです。