エンティティ オブジェクトが複数の jar に散らばっています。
jar AI には、@MappedSuperclass で注釈が付けられた基本クラス名 MyBase があります。
jar B には、MyBase から派生したエンティティ クラスがあります。
問題は、ウィービングがjarファイルのコンテキストで行われるため(私はmavenプラグインを使用しています)、基本クラス(MyBase)がインストルメント化されていないことです(そうすべきですが)。
派生クラスを jar B から A に移動すると、ウィービング プロセスでベースも処理されます。
私は大規模なプロジェクトに取り組んでいるので、モジュラー方式で開発することが重要です。
EclipseLink はそのような方法論をサポートしていませんか?
3 に答える
この制限を無効にする唯一の方法は、@ MappedSuperclass基本クラスが定義されているjarに一時エンティティクラスを追加し、ウィービング手順の後でそれを削除することです。
悲しいですが本当 ;-)
Maven プラグインについてはわかりませんが、両方の jar で静的ウィーバーを使用できるはずです。両方を織り込むには 2 回呼び出す必要があり、両方の呼び出しでウィーバー クラスパスに両方の jar が必要になります。
または、スーパークラスを含む jar を inpath として指定することもできます - hereおよびhere で説明されているように:
複数のプロジェクトの管理
AspectJ ソース コードのビルドには、2 つの異なるフェーズが必要です。.java および .aj ファイルのソースをコンパイルして .class ファイルを生成し、生成された .class ファイルにアスペクトを適用します。ウィービングと呼ばれるこの第 2 フェーズは、AspectJ コンパイラと Java コンパイラの主な違いです。Java コンパイル プロセスは、クラスパス設定によって制御されます。これにより、コンパイラが型を解決できるようになります。同じクラスパス設定が AspectJ コンパイル プロセスで使用され、Eclipse でもまったく同じ方法で設定されます。ただし、この設定は、すべての状況でコンパイルとウィービングの両方のステップを制御するには不十分です。これが、AspectJ プロジェクトで使用できる 2 つの追加設定がある理由です。
まず、inpath 設定があります。ここで指定されたものはすべてウィーバーで利用できるようになるため、適用されるアスペクトが織り込まれます。プロジェクトを右クリックして [プロパティ] を選択し、[AspectJ InPath] セクションに移動して、プロジェクトの inpath にエントリを追加できます。エントリは、別のプロジェクトの bin ディレクトリなど、JAR ファイルまたはディレクトリ (クラス フォルダ) のいずれかです。インパスにあるものはすべて、潜在的にアスペクトと織り込まれた後、プロジェクトの出力に送信されます。
2 番目の追加設定は、アスペクトパスです。インパスが織り込まれるもののリストを制御するのに対し、アスペクトパスはそのリストに織り込まれるものを制御します。つまり、アスペクトパスで指定されたアスペクトは、あたかもプロジェクト内にソース形式で存在するかのように、製織プロセスで利用できるようになります。この設定は、AspectJ Aspect Path プロパティ ページから制御され、JAR ファイルまたはディレクトリを含めることができます。
出力 JAR 設定は、各プロジェクトのプロパティ ページの AspectJ セクションにも表示されます。この設定により、コンパイラはクラス ファイルをプロジェクトの出力フォルダーではなく、JAR ファイルに直接出力します。
あなたと同じように私を夢中にさせました-これが役に立てば幸いです。;)