複数の Web アプリケーション (war) とライブラリ (jar) で構成されるシステムがあります。それらはすべてmavenを使用しており、私の管理下にあります（ソースコード、Nexusのビルドアーティファクトなど）。アプリケーション A がライブラリ L1 を直接使用し、L2 を間接的に使用しているとします (L1 から使用されます)。Maven の依存関係: ツリーまたはグラフ: プロジェクト プラグインを使用して、アプリケーションから依存関係ツリーをトップダウンで簡単に確認できます。しかし、誰が私のライブラリを使用しているかを確認するにはどうすればよいですか? 私の例から、A が L1 を使用する唯一のアプリケーション (またはライブラリ) であり、L2 が L1 と他のアプリケーション (B など) から使用されているかどうかを知りたいです。maven または nexus 用のプラグインはありますか、試してみるべきですかそのためのスクリプトを書くには？あなたの提案は何ですか？
質問する
2053 次
8 に答える
5
これをリポジトリ レベルで実現したい場合、Apache Archiva にはプロジェクト情報の下にリストされている「使用者」機能があります。
.
これは、アーティファクトの説明の「使用者」セクションにある mvnrepository.com の一覧に似ています。
残念ながら、Nexus は同等の機能を提供していないようです。
そのためだけにさらに別のリポジトリを維持するのは面倒だと思いますが、Nexus へのプラグインの作成など、他の回答の提案よりもおそらく簡単でしょう。Archiva は他のリポジトリをプロキシするように構成できると思います。
アップデート
実際、 「使用者」機能を実現するためのNexus 用のプラグインもあります。
于 2013-10-25T05:14:05.707 に答える
3
私の知る限り、これらの線に沿ったものはオープン ソース ツールとして存在しません。すべての pom を反復処理して分析することにより、リポジトリを走査し、他のすべてのコンポーネントでのコンポーネントの使用状況をチェックする Nexus プラグインを作成できます。ただし、すべてのコンポーネントを調べてすべての pom を解析する必要があるため、実行するのはかなり重いタスクになります。
同様の方法で、他のツールを使用してローカル リポジトリで実行できます。ただし、ローカル リポジトリよりもリポジトリ マネージャーのコンテンツを解析する方がおそらく理にかなっています。
于 2013-10-16T17:22:48.667 に答える
2
私はこの仕事のための公共図書館を知らないので、私のためにそれを行うカスタマイズされたアプリを書きました。一緒にバンドルされた 70 を超えるアーティファクトを含むディストリビューションを使用しています。アーティファクトを変更した後、変更が下位互換性があることを確認したい場合がよくあります (つまり、依存するアーティファクトにコンパイル エラーが発生しないようにするためです)。これを達成するには、変更されたアーティファクトのすべての依存関係を知ることが重要でした。
したがって、ディレクトリ（/サブディレクトリ）の下のすべてのアーティファクトをスキャンし、それらのpom.xmlを抽出し、（pomの依存関係セクションで）変更されたアーティファクトの発生を検索するアプリを作成しました。(私は Java でこれを行いましたが、シェル/Windows スクリプトはこれをさらにコンパクトに行うことができます。)
コードが役に立ったら、喜んで github で共有します。
于 2013-10-21T15:44:33.303 に答える
2
これを行うMavenの方法はないと思います。そうは言っても、これまたは同様のことを行う方法があります。いくつかの例を次に示します。
お気に入りの IDE でプロジェクトを開きます。たとえば、Eclipse はクラス レベルでの影響分析に役立ちます。ほとんどの場合、これで十分です。
grepソース ディレクトリで単純な " " を使用します。これは少し無愛想に聞こえるかもしれませんが (明白なことを述べているだけでなく)、おそらく、これを多く使用してきましたSonargraph や Lattix などの依存関係分析ツールを使用する
于 2013-10-15T23:35:20.783 に答える
1
おそらくもっと興味深いのは、この情報をどうするかということです。A の開発者に、重大なバグがあるため、ライブラリ L1 または L2 を使用しないように通知しますか? 私の意見では、リポジトリマネージャーで依存関係/親/プラグインのブラックリストを作成できるはずです。プロジェクトがブラックリストに登録されたアーティファクトを使用して展開/アップロードしようとすると、失敗するはずです。多くのプロジェクトが壊れる可能性があるため、そうではuploadingありません。downloading私の知る限り、これはまだどのリポジトリマネージャーでも利用できません。
于 2013-10-18T15:59:46.007 に答える
1
私見、そして私の経験からも、このような問題の技術的な解決策を探すのはやり過ぎです。アーティファクト (ライブラリ) を使用しているユーザーを知りたい理由が、アーティファクトまたは類似のものを変更するときに下位互換性を確保するためである場合は、従来のチャネルを使用して変更を伝え、他のユーザーを奨励することによって行うのが最善だと思います。ライブラリを使用してそれについて話している可能性のあるチーム (プロジェクトのブログ、wiki、電子メール、ドキュメンテーションが置かれているよく知られた場所、Jour fixe など)。
理論的には、リポジトリ内の各プロジェクトをクロールし、maven の build.xml を解析して (すべて maven を使用していると仮定して) スクリプトを作成し、アーティファクトへの依存関係が定義されているかどうかを確認できます。組織内のすべてのプロジェクトが標準の Maven 構造に従っている場合、そのようなスクリプトを 1 つ作成するのは簡単なはずです (ただし、これらのプロジェクトのいずれかが推移的な依存関係を介してアーティファクトに依存している場合は、少し複雑になる可能性があります)。
于 2013-10-24T10:59:32.850 に答える
1
この問題に対処する方法の 1 つは、Java 自体の外部にあります。問題の jar ファイルで fopen() の各ケースを追跡する OS レベルの監視スクリプトを記述します。これが企業環境にあると仮定すると、使用中のすべてのプロセスが少なくとも 1 回はライブラリにアクセスできるようになるまで、数週間 (!) 待たなければならない場合があります。
Windows では、Sysinternals Process Monitor を使用してこれを行うことができます: http://technet.microsoft.com/en-us/sysinternals/bb896645
Unix バリアントでは、DTrace または strace を使用します。
于 2013-10-20T15:58:46.787 に答える