問題タブ [dependency-management]

jQueryプラグインは、多くの場合、外部ファイル（jQueryライブラリ、スタイルシート（CSS）、画像、その他のプラグインなど）に依存しています。依存関係の配置に対処するjQueryプラグインを使用（および作成）するためのガイドラインは何ですか？つまり、必要なファイルはどこに配置する必要がありますか：メインアプリフォルダー（Img、Css、JS、または使用するフォルダー）の下、プラグインフォルダー（例：Plugins / MyPlugin / Img、Plugins / MyPlugin / Cssなど）の下または、他の何か？

プロジェクトにいくつかのプラグインを含めた後、他のプロジェクトメンバーが、どの依存関係が必要で、どのファイルをどこに配置するかを理解するのに苦労するのではないかと心配しています。

何がうまくいき、うまくいかなかったのですか？

もう一度それが起こりました...私は、相互依存関係を持ついくつかのプレーンなEclipse Javaプロジェクトで構成され、すべてプロジェクトビルドパスを介して管理される新しいプロジェクトに参加しました。これは少し混乱していると思います。そして、構成を実行することになると、あなたは地獄に入るだけです。

以前は、プレーンJavaプロジェクトではなく、プラグインプロジェクトを作成することに固執していました。たとえ、これらのプロジェクトをosgiバンドルとして実行するつもりがなかったとしてもです。プラグインプロジェクトでは、依存関係の管理がはるかに簡単であることがわかりました。他の人も同じ道を進んでいますか？このアプローチに反対するものはありますか？

Apache Axis、Commons HttpClient、Commons DBCP、Commons Transaction などのいくつかの Apache TLP (トップ レベル プロジェクト) に依存しています。

これらの各プロジェクトは JCL (Commons Logging) に依存しており、すべてのプロジェクトは異なるバージョンの JCL に依存しています。

どのバージョンの JCL を選択すればよいですか? 最新のバージョンが最適な選択でしょうか? 上位バージョンの JCL は、下位バージョンに対してコンパイルされたプロジェクトと互換性がありますか? JCL プロジェクト自体がこの情報をどこかに伝えていますか?

これは主にPHPに関する質問です。私は疑問に思っていました: (運用) サーバーへの展開を行うときに、必要なすべてのライブラリがアプリケーションにパッケージ化されていることをどのように確認しますか?

より具体的な例: Zend Framework で実行されているアプリがあり、アプリケーションをサーバーにロールするたびに、展開プロセスによってそのシステムに新しい「インストール」が作成されます。したがって、Zend Framework をアプリケーションと一緒にバンドルし、ファイルを適切な場所に一緒にコピーする必要があります (これは自動的に行われます)。現在、展開中に Zend の SVN システムからファイルを取得するために svn:externals 定義を使用していますが、その SVN に依存したくなく、展開ごとに外部 SVN にトラフィックを送りたくありません。 .

Java の世界では、中央アーティファクト リポジトリを使用してそのようなものを処理する Maven に慣れています。Maven4PHP バージョンがあることは知っていますが、PHP ベースのソリューションをもっと探しています。さらに、アプリケーション (ライブラリを含む) を単一のデプロイ可能ファイルにバンドルするという私の要件を実際には満たしていないため、PEAR が良い方法だとは思いません。

私が気付いていない、すでに利用可能なツールはありますか? または、私が知っておくべき優れたテクニックはありますか?

助けてくれてありがとう！

マイケル

独立して開発されたいくつかのコンポーネントを含むプロジェクトがあります。それでも、さまざまなスケジュールのさまざまな製品として名前が付けられた多くのリリースがあります。コンポーネントに新しいバージョン (おそらくバグ修正に関連するもの) がある場合は、すぐにフィードバックを得たいと考えています。したがって、そのバージョンに依存するすべての製品も同様に更新されます。

もちろん、これは単純な例です。このシナリオ専用のプロジェクトがあるはずですが、見つかりませんでした。そのような状況に対処するために何をしますか？推奨される (簡単で強力な) 方法は何ですか?

プロジェクト間でAntターゲットを共有する確立された方法はありますか? 私は現在解決策を持っていますが、それは少しエレガントではありません。これが私がこれまでに行っていることです。

ivy-tasks.xmlネットワーク上のサーバーでホストされているというファイルがあります。このファイルには、他のターゲットとともに、Ivyでプロジェクトの依存関係を管理するためのボイラープレート タスクが含まれています。例えば：

このファイルがホストされている理由は、次のことをしたくないからです。

• ファイルを必要とするすべてのプロジェクトにファイルをチェックインします。これにより重複が発生し、ターゲットの維持が難しくなります。
• build.xml をソース管理からのプロジェクトのチェックアウトに依存させます。これにより、ファイルにアクセスするためだけに、ビルドの最上位に XML が追加されます。

プロジェクトの build.xmls でこのファイルを使用して行うことは、次の行に沿っています。

これに関する「汚い」部分は、 import タスクが最上位にある必要があるため、target の外で上記の手順を実行する必要があることです。さらに、必要なすべての build.xml ファイルにこの XML を含める必要があります (つまり、まだ多少の重複があります)。

その上、インポートしたい一般的な (Ivy 以外の) タスクがある可能性がある追加の状況があるかもしれません。Ivy の依存関係管理を使用してこれらのタスクを提供する場合、依存関係を解決するまでに build.xml のターゲット内にいる必要があり、インポートできないため、まだ問題があります (上記の制約に）。

私が達成しようとしていることに対するより良い解決策はありますか?

コマンドを使用して正常にビルドできるMavenGrailsプロジェクトをビルドしましたmvn grails:war。

ただし、標準を使用するmvn installと機能しません。ドメインクラスの1つが見つからないため、util Javaクラス（grails-app / utilフォルダーの下にあります）をコンパイルできないという例外が発生します。

パッケージ構造を使用していないため、ドメインクラスはutilクラスにインポートされません。

私の最初の質問は、MavenがMavenizedGrailsプロジェクトの構築を完全にサポートしているかどうかだと思います。私はmvn install働くことを期待すべきですか？

私の2番目の質問は、-を使用してアプリをビルドするmvn grails:war必要がある場合、親プロジェクト/ pomが依存モジュールとしてそれを持っているときにこれを強制するにはどうすればよいですか？

Groovy 1.7-beta-1 に依存するプロジェクトを実行しています。gmaven プラグインは、groovy バージョン 1.6 を依存関係として使用します。私の pom では、依存関係管理セクションで grooyv-all バージョンを次のように指定します。

しかし、maven をデバッグ モードで実行すると、gmaven プラグインへの依存関係に groovy 1.6 が使用されていることがわかります。私の依存関係管理セクションはこれをオーバーライドするので、すべて 1.7-beta-1 を使用すると思っていましたが、グルーヴィーなバージョンが異なるためにエラーが発生しています。ここで何か助けていただければ幸いです。

ありがとう、

ジェフ

1つの会社の親pomがあります。これは、dependencyManagementを使用して、使用されるすべてのアーティファクトのすべての依存関係のバージョンを管理します。

憂慮すべきことは、SNAPSHOTバージョンをdependencyManagementで定義できることです。ただし、Mavenリリースが実行されると、dependencyManagementでSNAPSHOTバージョンを使用してpomをリリースできます。なんで？

子プロジェクトを会社の親pomのリリースされたバージョンにポイントし、この子プロジェクトがSNAPSHOTバージョンであるにもかかわらずdependencyManagementで定義された依存関係を使用する場合、子プロジェクトをリリースできません。

MavenがdependencyManagementで定義されたアーティファクトのSNAPSHOTバージョンのリリースを許可するのはなぜですか？また、SNAPSHOTバージョンが定義されている場合に、Mavenリリースプラグインが失敗するように構成するにはどうすればよいですか？