10

Maven を使用してビルドしたいクローズド ソース プロジェクトがあります。私が見つけた公開リポジトリでは利用できない2つのJavaライブラリに依存しています(この場合はlibGoogleAnalytics.jarとFlurryAgent.jarですが、質問はクローズドソースの依存関係に適用されます)。

アプリケーションのビルドに使用する依存関係とまったく同じバージョンを使用して、組織内の誰もがアプリケーションをビルドできるようにしたいと考えています。これには、私の同僚と私たちのビルド サーバーが含まれます。


Maven が解決方法を知らないクローズドソースの依存関係を管理するにはどうすればよいですか?

明らかに、私は各人のマシンに行き、「mvn install:install-file」を手動で実行してバイナリを Maven リポジトリに入れることができますが、そのような依存関係を手動で管理すると、依存関係マネージャーの目的が無効になります。

maven のInternal Repositoriesのドキュメントに従って、どこかにリポジトリ サーバーをセットアップし、そこにバイナリを配置して、すべての開発者がアクセスできるようにすることができました。しかし、それは私が維持する新しいサーバー（または少なくとも既存のサーバー上の新しいウェブサイト）を持っていることを意味します。また、外部の関係者がリポジトリにアクセスできないようにするために、アクセス許可について心配する必要があることも意味します。また、リポジトリが利用できない場合に開発者が問題に遭遇しないように、バックアップと可用性について心配する必要があることも意味します。

既存の scm (この場合は hg ですが、git や svn など) を使用して依存関係を保存できれば、これらの問題はすべて解消されます。私たちのソース管理リポジトリはすでにバックアップされており、ビルドを行う開発者は基本的にいつでも利用でき、その権限はすでに処理されています。

しかし、hg を使用して Maven の依存関係を管理する方法をまだ理解できていません。

4

3 に答える 3

10

Manfred の答えは、私にとってはうまくいかなかったことがわかりました。アプリはコンパイルされましたが、必要な Google アナリティクス クラスが見つからなかったため、Android デバイスで実行されませんでした。

彼が提供したリンクをたどると、実際には少しクリーンで適切に機能するこのソリューションを発見しました。

要約すると、次の依存関係を pom.xml に追加しました。groupId、artifactId、および version はすべて、適切な値を使用して私が作成しました。

<dependencies>
    ...
    <dependency>
        <groupId>com.google.android.apps.analytics</groupId>
        <artifactId>libGoogleAnalytics</artifactId>
        <version>1.1</version>
    </dependency>
    <dependency>
        <groupId>com.flurry</groupId>
        <artifactId>FlurryAgent</artifactId>
        <version>1.24</version>
    </dependency>
</dependencies>

次に、プロジェクトのソース ツリーにサード パーティの依存関係を格納する場所のリポジトリ定義を追加しました。

    <repository>
        <id>third.party.closed.source.repo</id>
        <url>file://${basedir}/../maven_repo_3rd_party</url>
    </repository>

次に、jar ファイルを次の場所に移動しました。

./maven_repo_3rd_party/com/google/android/apps/analytics/libGoogleAnalytics/1.1/libGoogleAnalytics-1.1.jar
./maven_repo_3rd_party/com/flurry/FlurryAgent/1.24/FlurryAgent-1.24.jar

これを行うと、サードパーティの依存関係が公式の Maven リポジトリから解決されたかのように、私のプロジェクトがコンパイルされ、実行されました。

于 2011-02-10T19:15:03.937 に答える
5

専用のリポジトリ サーバーを使用する必要があると本当に思いますが、Sean Patrick はそれについて完全に正しいと思いますが、これを機能させるためのハックを次に示します。

昔と同じようにjarファイルをlibsフォルダーに入れます（Ant.. ouchを思い出してください）..そして、スコープシステムとパスを使用して各jarへの依存関係を宣言します。

これを行うことができる例は、ここで説明されています

http://www.simpligility.com/2010/01/how-to-mavenize-a-typical-web-application-build-jasperserver-3-7-sample-webapp/

具体的には、依存関係は次のようになります

<dependency>
  <groupId>jasperreports</groupId>
  <artifactId>jasperreports-chart-themes</artifactId>
  <version>3.7.0</version>
  <scope>system</scope>
  <systemPath>${project.basedir}/src/main/webapp/WEB-INF/lib/jasperreports-chart-themes-3.7.0.jar</systemPath>
</dependency

ああ、それを行う方法を説明したので、これは悪い習慣であり、多くの問題があることを覚えておいてください。しかし、うまくいくでしょう...

于 2011-02-10T17:03:34.663 に答える
3

専用のリポジトリ サーバーを使用する

Maven の Internal Repositories のドキュメントに従って、どこかにリポジトリ サーバーをセットアップし、そこにバイナリを配置して、すべての開発者がアクセスできるようにすることができました。

丁度。次のような複数のリポジトリを使用して Maven リポジトリ サーバーをセットアップします。

  • internal-releases
  • internal-snapshots
  • external-opensource
  • external-closedsource（これは、私たちが話しているlibが行く場所です）

しかし、それは私が維持する新しいサーバー（または少なくとも既存のサーバー上の新しいウェブサイト）を持っていることを意味します。また、外部の関係者がリポジトリにアクセスできないようにするために、アクセス許可について心配する必要があることも意味します。

はい。しかし、本格的なソフトウェア開発を行う企業には、そのようなインフラストラクチャが必要です。しかし、あなたの会社が Maven の使用に真剣に取り組んでいるのであれば、おそらく構成管理専用の役職もあるはずであり、その人がこのサーバーを管理する必要があります。

また、リポジトリが利用できない場合に開発者が問題に遭遇しないように、バックアップと可用性について心配する必要があることも意味します。

標準のレポジトリ サーバー ( Sonatype Nexusなど) は堅実です。ハングした場合は、実行中のアプリ サーバー/サーブレット コンテナーを再起動するだけです。また、開発者がリポジトリからライブラリをダウンロードすると、それはローカル リポジトリに残ります。そのため、リポジトリがダウンしても問題はないはずです (ただし、サーバーがダウンしている場合、新しい依存関係を参照することはできません)。 .

既存の SCM を Maven リポジトリとして使用する

SCM を Maven リポジトリとして本当に使用したい場合は、次のようにします。

http://maven-svn-wagon.googlecode.com/svn/site/index.html

この記事では、独自のプロジェクト用に SVN ベースの Maven リポジトリをセットアップする方法について説明します。ただし、サードパーティをリポジトリにデプロイする場合は、ここに記載されている構成で pom を作成し、その pom を使用してライブラリをdeploy:deploy-fileします。

(他にも wagon / scm 実装があり、構成は少し異なりますが、解決策は同じです: 使用している wagon 実装に従って pom を作成してから実行しますdeploy:deploy-file(詳細については、使用方法のページを参照してください) 。

于 2011-02-10T16:29:54.217 に答える