14

一部のプロジェクトがEclipseプラグイン/OSGIバンドルプロジェクト（RCPアプリケーション）であり、他のプロジェクトが単なる古いJavaプロジェクト（Webサービスモジュール）である混合プロジェクトタイプ間のプロジェクト間依存関係を処理するためのベストプラクティスを探しています。Eclipseプラグインの中にはJavaプロジェクトに依存しているものはほとんどありません。

私の問題は、少なくとも私が見た限りでは、EclipsePDE環境でそのような依存関係をきれいに表現する方法がないということです。プラグインプロジェクトを他のプラグインプロジェクト（Import-PackageまたはRequire-Bundleマニフェストヘッダー経由）に依存させることはできますが、プレーンJavaプロジェクトに依存させることはできません。

プロジェクトにワークスペース内の別のプロジェクトからのjarへの依存関係を宣言させることができるようですが、これらのjarファイルはエクスポート構成でも起動構成でも取得されません（ただし、Javaコード編集ではライブラリは問題なく表示されます）。

「Javaプロジェクト」は、J2EEコンテナ（現時点ではJBoss 4.2.2）にデプロイされるサービスを構築するために使用され、場合によっては複数のjarを生成します。1つはJBoss earにデプロイするためのもので、もう1つはクライアントコードで使用するためのものです（ RCPアプリケーション）。

今のところこの問題を「解決」した方法は、さらに2つの外部ツールランチャー構成があることです。1つはすべてのjarをビルドするためのもので、もう1つはこれらのjarをプラグインプロジェクトにコピーするためのものです。これは（一種の）機能しますが、「ビルド全体」と「jarのコピー」ターゲットは、非常に大きなビルドステップを必要とし、Eclipseのインクリメンタルビルド機能全体をバイパスし、プロジェクトを参照するだけでなく、jarをコピーすることで、依存関係情報を分離します。そして、それがキャンディーであるかのように開発時間を浪費する非常に大規模なワークスペースの更新を要求します。

私が望んでいるのは、プロジェクト間の依存関係を管理し、必要な場合にのみ増分再構築を要求し、RCPアプリケーションプラグインのサービスライブラリからクライアントコードを使用できる、はるかに「自然な」ワークスペースセットアップです。必要なすべての必要なクラスを使用してRCPアプリケーションを起動します。

だから私は私のケーキを持ってそれも食べることができます;）

ノート

明確にするために、これはEclipse PDE構成に関するものであるため、現時点では依存関係管理やモジュール管理に関するものではありません。

私は[Maven]、[Ivy]、[Buckminster]などの製品をよく知っており、まったく異なる問題を解決します（ワークスペース構成の問題を解決すると、これらの製品は実際にワークスペースの具体化と構築に役立ちます。製品）

4

8 に答える 8

11

Eclipseプロジェクトは、プロジェクトのプロパティ（依存プロジェクト？）のチェックボックスによって相互に依存しています。これは、Eclipseがどちらをビルドするかを決定する方法です。これは自分で設定できますが、通常はJavaビルドパスを変更するときに設定されます。データは.projectファイルIIRCに保存されるため、GUIを確認して変更内容を確認すると、他のファイルをより柔軟に適用できます。

ただし、JarsとBundlesを組み合わせて使用​​したいようです。これを行う簡単な方法は、すべてのプロジェクトをJavaプロジェクトとして扱うことです。PDEプロジェクトでは、実際にJavaビルドパスを調整できます。不平を言い、それを行うのは正しい方法ではないと言うでしょうが、それはあなたがPDEプロジェクトをJavaプロジェクトに依存させることを可能にします。そうは言っても、このアプローチでランタイムの問題があったとしても、私は驚かないでしょう。PDEランタイムはそれをそのように認識しない可能性があります。

もう1つのアプローチは、JAR自体をPDE/OSGiバンドルにすることです。結局のところ、OSGiバンドルは、マニフェストに少し余分なものが含まれているJARにすぎず、自動依存関係管理を使用してプロジェクトを簡単に開発およびアセンブルできます。マニフェストをバンドルに含める必要がない場合でも、これがおそらく最も簡単な方法です。ただし、これを行うと、必要に応じて各プラグインにライブラリを埋め込むのではなく、よりモジュール化されたアプローチでPDEアプリを出荷できるようになります。

したがって、PDEはOSGiバンドルを生成できます。これは、JAR+マニフェストのものの単なる別名です。JARは、他の環境（EARや他のクライアントでの使用など）でもまったく同じように使用でき、アプリでOSGiレイヤーを利用できます。あなたが話しているハイブリッドバンドルのタイプを考えると、これを行わない理由は本当にありません。

于 2009-09-23T19:07:57.100 に答える
4

私はそれをやったことがないので、これは理論的なアプローチです。しかし、私はivyやmaven2のような依存関係管理システムを試してみます。

maven2は依存関係の管理よりもはるかに多くのことを行うので、この場合はivyをお勧めします。

于 2009-09-07T17:20:49.013 に答える
3

このソリューションでは、Antビルダーを使用して、プレーンJavaプロジェクトの「クラス」ディレクトリをプラグインプロジェクトのトップディレクトリに直接コピーします。時間を節約するためにJAR構築ステップをスキップし、それはかなりうまく機能します。プラグインプロジェクトがすでにビルドされている外部JARに依存している場合は、それらもコピーします。

Eclipse 3.5で設定する方法は次のとおりです（フォーマットがおかしいので申し訳ありませんが、インデントを保持するために見つけることができる唯一の方法です）。

Create empty "classes" dir in plugin project
Select plugin project, hit F5 to refresh resources
Create new Ant build file in plugin project to copy dependencies (ours is shown below)

Right-click plugin project, select Properties
  Select Builders
  Click "New..." (brings up Edit Configuration dialog)
    Select Ant Builder and click "OK"
    Name your builder (ours is called "PluginProject externals")
    Browse workspace for Buildfile (ours is ${workspace_loc:/PluginProject/copyDependencies.xml})
    click Refresh tab
      check "Refresh resources upon completion", click "Specific resources"
      click "Specify Resources...", check box for the classes dir, click "Finish"
  Click "OK" (closes Edit Configuration dialog)
  Click "Up" to move "PluginProject externals" to top of builder list
Click "OK" (closes Properties dialog)

Open your plugin project's MANIFEST.MF
Click "Runtime" tab
Click "Add..." under "Classpath", select your the "classes" dir and JARs and click "OK"

プラグインプロジェクトに空の「classes」ディレクトリを手動で作成すると、新しいビルダーにそのリソースを更新するように指示できます（新しいビルダーが実行される前はまだ存在していません）。copyDependencies.xmlファイルの内容は次のとおりです。

<project name="Copy dependencies" default="copyDependencies" basedir=".">
  <!--
    This copying is needed because it appears that Eclipse plugins can't
    depend directly on external Eclipse projects.
  -->
  <description>
    Copies external dependency class andd JAR files into this plugin's directory.
  </description>

  <target name="copyDependencies">
    <copy file="../External/JDOM/jdom-1.0/build/jdom.jar" todir="." preservelastmodified="true"/>
    <copy file="../External/Xalan/xalan-j_2_6_0/bin/xalan.jar" todir="." preservelastmodified="true"/>
    <copy file="../External/Xalan/xalan-j_2_6_0/bin/xercesImpl.jar" todir="." preservelastmodified="true"/>
    <copy file="../External/Xalan/xalan-j_2_6_0/bin/xml-apis.jar" todir="." preservelastmodified="true"/>
    <copy todir="./classes/com/arm" preservelastmodified="true">
      <fileset dir="../Utilities/src/com/arm" excludes="**/*.java"/>
    </copy>
  </target>
  <target name="clean" description="Deletes local copies of external classes and JARs.">
    <delete file="jdom.jar" quiet="true"/>
    <delete file="xalan.jar" quiet="true"/>
    <delete file="xercesImpl.jar" quiet="true"/>
    <delete file="xml-apis.jar" quiet="true"/>
    <delete dir="./classes/com/arm/utilities" quiet="true"/>
  </target>
</project>

このメソッドの唯一の欠点は、Eclipseを呼び出す必要があるときに、外部ビルダーを呼び出すことについて100％完全ではないことです。そのため、Eclipseで「プロジェクト>クリーン...」を実行して強制する必要がある場合があります。 。

于 2009-11-09T20:04:28.167 に答える
1

お見舞い申し上げます。私もこの問題とEclipse開発者のWall-of-Silenceと、プラグインから通常のJavaプロジェクトへの依存関係を宣言する方法（実行時に機能するように）について、このような単純で明白な質問と戦ってきました。

私は彼らがそれを支持するとは思わない。この問題を回避する唯一の方法は、プラグインプロジェクト内に、実際にはJavaプロジェクトのbin /フォルダーにリンクするフォルダーを作成し、これらのフォルダーをプラグインに含めることです。それは少なくとも機能しますが、必要な絶対ファイルシステムパスのために脆弱です。

于 2010-03-12T11:11:36.907 に答える
1

Eclipseで「プロジェクトプロパティ」->「デプロイメントアセンブリ」を使用して、メインプロジェクトに他のプロジェクトを追加できる場合があります。他のプロジェクトは、デプロイメントファイル（war、earなど）に自動的に追加される「jar」のように見えます。多分これはうまくいくかもしれません。少なくともそれは私にとってはうまくいきます。幸運を ！！

アリサンデス。

于 2010-10-24T21:01:19.830 に答える
1

ビルドパスのプロパティには、プロジェクトの追加のソースフォルダを定義できる「リンクソース」オプションがあります。別のワークスペースプロジェクトの「src」フォルダを選択して、「src2」などの名前に変更できます。このようにして、クラスはコンパイルされ、プラグインプロジェクトの出力フォルダーにデプロイされ、実行時にロードできます。

于 2011-12-06T21:57:37.380 に答える
0

ビルドの依存関係の複雑なセットを使用すると、Maven2とHudson（CI用）が非常に優れた組み合わせであることがわかりました。インフラストラクチャをセットアップして構成に頭を悩ませるのにしばらく時間がかかりましたが、その後はうまくいきました。

もちろん、ビルドメカニズムはMaven2（またはHudson）のサポートに依存しています。Eclipseヘッドレスビルドがどれだけうまくサポートされているかわかりません。しかし、Eclipseヘッドレスを使用している唯一の理由が、依存関係を1つの場所で表現できるようにすることである場合は、自分で賛成して切り替えてください。

于 2009-09-08T07:48:51.183 に答える
0

私はまったく同じ問題を抱えています。Mavenでビルドできる複数の通常のJavaプロジェクトのセットがあり、正しく機能するには（現在）すべて同じクラスパスを共有する必要があります。これらのプロジェクトは、OSGi以外の環境でサーバーを起動するために使用できます。次に、これらのプロジェクトを1つのバンドルとして使用するEclipseRCPクライアントもあります。Apache Felix Mavenバンドルプラグインを使用して、Mavenでこの1つの大きなバンドルを完全に構築でき、すべてが正常に機能します。ただし、通常のプロジェクトで1つのクラスを変更するたびに、バンドル全体を再構築する必要があります。インクリメンタルビルドとリソースリンクは機能しません。

これらのプロジェクトのバイナリ/ソースディレクトリをone-big-bundleのマニフェストクラスパスにリンクする「ソリューション」を試しましたが、機能しているように見えますが、個々のファイルをリンクする必要があるため、メンテナンスの悪夢になります。

皮肉なことに、クライアントでOSGiを使用しているため、実際には、Mavenモジュールを備えた優れたモジュラー構造を1つのプラグインプロジェクトのサブパッケージに折りたたむことを考えています。これは、開発が非常に遅いよりも優れた代替手段です。

私が最初に調査する他のより良い代替案（OSGiの人によると）は、すべてのMavenモジュールをOSGiバンドルにすることです。しかし、これは実際のPITAである可能性があります。これは、クラスパススキャンと、複数のバンドル（同じ名前の場合もある）からの複数の構成ファイルを組み合わせて1つの構成を形成することに依存しているためです。

（具体的には、Springフレームワークを使用し、複数のpersistence.xmlファイルを1つの永続コンテキストにマージします。また、Springで使用される1つのSpringコンテキストを形成する必要がある異なるモジュール（すべて異なるASPECTを提供）からのいくつかのSpringXMLコンテキストファイルをマージします。 -DM。）

于 2010-06-14T09:36:43.997 に答える