4

Java アプリケーションで使用しているライブラリがあります。これは特定の機能にとって重要ですが、オプションです。JAR ファイルが存在しない場合、プログラムは問題なく続行されます。プログラムをオープンソースにしたいのですが、API を使用するための import ステートメントが多数あるため、ソース コードをコンパイルするために必要なこのライブラリを含めることができません。2 つのコード セットを維持したくありません。オープン ソース リリースから物理的な jar ファイルを削除する最善の方法は何ですか?

4

3 に答える 3

3

おそらくこれを修正する方法はいくつかありますが、ここに私が考えることができるいくつかの方法があります：

  • サードパーティ ライブラリで呼び出す必要があるメソッドが 2 つしかない場合は、リフレクションを使用してそれらのメソッドを呼び出すことができます。それは非常に冗長なコードを作成しますが、それは読みにくいものです。

  • 使用するサードパーティ ライブラリに API があまりない場合は、ライブラリ内のクラスの非機能シェル (同じ名前とメソッドを持つ型のみ) を含む別の JAR ファイルを作成することもできます。同じ署名で）。その後、この JAR を使用して配布およびコンパイルできます。実行時に、可能であれば実際の JAR に置き換えます。

  • 最も一般的な方法は、おそらく、サード パーティのライブラリに依存するコード用に別のモジュール/プロジェクトでラッパー API を作成し、ビルド済みの JAR を配布することです。これは、2 つのコード セットを維持したくないというあなたの希望に反するかもしれませんが、長期的には最善の解決策であり、苦痛の少ない解決策であることが証明されるかもしれません。

于 2013-05-29T20:31:13.043 に答える
3

smallworld とほとんど同じことを 1 つ追加して入力していました。この API が必要な場合は、Maven などのプロジェクト ビルド ツールを使用して、プロジェクトの依存関係を処理できます。誰かが pom を使用してソース管理からチェックアウトすると、依存関係を自分でダウンロードできるため、ソース リポジトリに含める必要はありません。

于 2013-05-29T20:24:48.647 に答える
3

典型的なアプローチは、ラッパー API (つまり、インターフェイス) を定義し、それらのインターフェイスをオープン ソース コードに含めてから、特定のインターフェイスを実装するクラスのクラス名を指定できる構成オプションを提供することです。

クラスをオープン ソース コードに直接インポートする代わりに、API インターフェイスをインポートします。この方法では、API をオープン ソース化しますが、オープン ソース化したくない部分やオープン ソース化できない部分の実装はオープン化できません。

多くの例がありますが、初心者向けに JDBC API (インターフェース) と JDBC ドライバー (実装クラス) を見てください。

于 2013-05-29T20:18:49.587 に答える