Wie kann überprüft werden, ob das Paket im Annotationsprozessor vorhanden ist (während der Kompilierung)?

Question

Ich baue einen Annotation Processor für Android (aus Gründen zukünftiger Erklärungen nennen wir es TestProcessor).

Der Plan ist für den Prozessor in zwei Betriebsarten zu arbeiten:

• Mode 1: Erzeugung des Codes A

• Mode 2: Erzeugung des Codes A und B

---

Mode 2 sollte nur dann, wenn das zusätzliche (optional) ausgewählt wird Paket in der Umgebung vorhanden ist, für die der Prozessor Code erzeugt.

Gibt es eine Möglichkeit in der process Methode des Annotation Processors herauszufinden, wenn das optionale Paket existiert?

---

EDIT 1:

Kleine Klarstellung der "(optional) Paket". Mit dem zusätzlichen Paket meine ich ein Java-Paket, das kann, muss aber nicht im Projekt existieren (das heißt mit dem Prozessor). Das optionale Paket kann beispielsweise den Inhalt einer externen Bibliothek darstellen. Die externe Bibliothek kann, muss aber nicht im Projekt enthalten sein.

Lassen Sie mich nur ein kleines Beispiel machen:

• Nehmen wir an, wir haben ein (ein Modul) Projekt Sample.
• Sample verwendet meine TestProcessor.
• die Square'sPicasso als Beispiel für eine externe Bibliothek
• Wenn Sample HAS Square'sPicasso als eine ihrer Abhängigkeiten nehmen lassen, arbeitet TestProcessor in Mode 2 und Code A und B erzeugt. Mit anderen Worten: Wenn Sie problemlos Klassen von com.square.picasso (in Sample) verwenden können, sollte der Prozessor in Mode 2 arbeiten.
• Wenn es keine Square'sPicasso in Sample's Abhängigkeiten betreibt TestProcessor in Mode 1 und erzeugt nur Code A.

---

EDIT 2:

Ich dachte an zwei Abhilfen für dieses Problem:

1. Verwendung von zwei Arten von Annotationen für zwei processorModes (Beispiel: @DoStuffModeOne , @DoStuffModeTwo)
2. eine zweite Art von Anmerkung Verwendung (das zum Beispiel auf den Application verwendet werden soll), die die Verwendung von Mode 2 (Beispiel: @TriggerModeTwo) löst

Für meinen Fall der zweite Problemumgehung ist viel mehr bevorzugt, aber ist immer noch viel schlechter als es wäre, wenn die TestProcessor selbst entscheiden könnte, welche Mode zu wählen.

Answer 1

Sie können eine der Klassen im Klassenpfad der Anwendung überprüfen. Führen Sie dann Ihre Logik basierend auf dem Ergebnis des Checks aus.

Answer 2

Sie könnten diesen Code verwenden, um herauszufinden, ob eine Klasse in der Annotationsverarbeitungsumgebung vorhanden ist.

TypeElement typeElement = processingEnvironment.getElementUtils(). 
    getTypeElement("com.squareup.picasso.Picasso"); 

ich keinen Erfolg hatte mit der Elements.getPackageElement() Methode, weil sie erfolgreich für nicht vorhandene Pakete (zumindest unter Eclipse) zurückgeführt und zur Durchführung des PackageElement.getEnclosedElements() Methode auf Pakete wie diese erstellt leer war auch für Nicht-leer Pakete. Ich würde vorschlagen, dass Sie für eine bestimmte Klasse in Ihrem Paket von Interesse gehen, wie in meinem vorherigen Beispiel, weil es wie erwartet für vorhandene Typelemente funktioniert und null für nicht vorhandene Typen zurückgibt.

ich zur Zeit keine Annotation Verarbeitungs-API basierende Methode gefunden, um zu entscheiden, ob der Typ Element auf diese Weise gefunden auf einer Datei Quellcode basiert auf dem Quellpfad des Projekts oder einer binären Klassendatei auf der Kompilierungsklassenpfad. Es könnte eine Methode dafür geben, die processingEnvironment.getFiler().getResource(StandardLocation.SOURCE_PATH, ...) miteinbezieht, aber leider nicht tragbar ist, weil StandardLocation.SOURCE_PATH in Eclipse nicht unterstützt wird.

Ich hoffe, das hilft.

Answer 3

Zusätzlich zu der Lösung vorgeschlagen JBirdVegas; Mit dieser Funktion kann geprüft werden, ob in den externen Bibliotheken zur Laufzeit ein Paket existiert.

public static boolean packageExists(String packagePath) { 
    return Thread.currentThread().getContextClassLoader().getResource(packagePath) != null; 
} 

Verbrauch:

packageExists("apackage/innerpackage")