次のサンプル ソース コードがあります。
public interface SomeInterface {
void method1();
@Support
void method2();
@Support(ENVIRONMENT_A)
void method3();
@Support({ ENVIRONMENT_A, ENVIRONMENT_B })
void method4();
}
上記の API はさまざまな環境で使用できますが、その中にはA
とB
(たとえば、A=Oracle、B=MySQL) があります。どのメソッドがどの環境でサポートされているかを伝えるために@Support
、次のセマンティクスで注釈を追加しました。
- 注釈がない
@Support
ということは、対応するメソッドが環境に依存しないことを意味します - 「空の」
@Support
注釈は、対応するメソッドがすべての環境でサポートされていることを意味します - パラメータ化
@Support
されたアノテーションは、対応するメソッドがアノテーション引数として提供された環境でのみサポートされることを意味します。
この API クライアントとの通信を改善するために、API の前処理に使用できる Maven プラグインを作成したいと考えています。そのプラグインは、提供されたすべての環境でサポートされないすべてのメソッドを廃止するために、環境のリストをパラメーターとして受け取ります。
いくつかの例:
- プラグインを次のように実行し
ENVIRONMENT_A
ます。インターフェースに影響はありません。すべてのメソッドがサポートされていますENVIRONMENT_A
プラグインを
ENVIRONMENT_B
次のように実行します。結果のインターフェイスは次のようになりますpublic interface SomeInterface { void method1(); @Support void method2(); /* @deprecated - Not supported in ENVIRONMENT_B */ @Support(ENVIRONMENT_A) @Deprecated void method3(); @Support({ ENVIRONMENT_A, ENVIRONMENT_B }) void method4(); }
ENVIRONMENT_A
と の両方でプラグインを実行しますENVIRONMENT_B
。public interface SomeInterface { void method1(); @Support void method2(); /* @deprecated - Not supported in both ENVIRONMENT_A *AND* ENVIRONMENT_B */ @Support(ENVIRONMENT_A) @Deprecated void method3(); @Support({ ENVIRONMENT_A, ENVIRONMENT_B }) void method4(); }
つまり、プラグインは、src/main/java のソースをコンパイルする前に、上記のルールに従って src/main/java のすべてのソースを変換する必要があります。これをいつでも再現できるようにするには、元のソースをそのままにしておく必要があります。これは可能ですか?