Как обработчик аннотации java читает и обрабатывает аннотации из projectA и генерирует исходные файлы Java для projectB

Question

Я создал аннотацию java, которая отмечает некоторые из моих «служебных» классов как сервисы, а затем написала обработчик аннотации, который генерирует соответствующий servicerequest и классы обслуживания. Это для проекта GWT maven, где сервисные запросы отправляются на сервер к центральному диспетчеру для обработки различными службами.

Мой проект maven состоит из родительского проекта и проектов с 5 модулями.

Структура проекта что-то вроде этого:

• MoodleMobile(родительский Maven проект)
  • gwtMoodleWS(GWT слой)
  • moodleBuildSupport(содержит аннотация processo г)
  • moodleGeneratedServiceHandlers(желаемое место генерируемых классов)
  • moodleWS(серверный слой)
  • moodleWSAPI(местоположение кода, где процессор аннотаций будет работать)

Мой вопрос в том, что.

Каким образом можно обработать обработчик аннотаций и обработать аннотации из одного проекта (moodleWSAPI) и создать исходные файлы java в другом проекте (moodleGeneratedServiceHandlers)?

Я, кажется, много примеров обработчиков аннотаций, создающих исходные файлы java для того же проекта, в котором работает обработчик аннотации, но не для другого проекта.

Я успешно построил и протестировал свой обработчик аннотации, но не могу понять, как заставить его создавать файлы за пределами проекта, в котором работает процессор. В настоящий момент он создает исходные файлы java в moodleWSAPI (это не верно). Я хочу, чтобы он обрабатывал исходные файлы в moodleWSAPI, а затем выводил новые сгенерированные исходные файлы в moodleGeneratedServiceHandlers.

Вот фрагмент кода, который я должен создать реальный исходный файл Java ..

public void createSourceFileFromTemplate(Template template, ClassSignature classSignature, VelocityContext context, Element element) { 
     PrintWriter pw = null; 
     try { 
      JavaFileObject sourceFile = processingEnv.getFiler().createSourceFile(classSignature.getFullName(), classSignature.getElement()); 
      OutputStream fileStream = sourceFile.openOutputStream(); 
      pw = new PrintWriter(fileStream); 
      template.merge(context, pw); 
     } catch (Exception e) { 
      e.printStackTrace(); 
      if (element!=null) { 
       processingEnv.getMessager().printMessage(Kind.ERROR, e.getMessage(),element); 
      } else { 
       processingEnv.getMessager().printMessage(Kind.ERROR, e.getMessage()); 
      } 
     } finally { 
      if (pw!=null) { 
       pw.close(); 
      } 
     } 
    } 

Пожалуйста, обратите внимание: ClassSignature только мой собственный класс, я использую, чтобы захватить имя класса класса. Я использую Velocity как мой механизм шаблонов для создания фактического источника java.

Я ничего не вижу в спецификации processingEnv.getFiler(), которая позволяет мне указывать выходные данные вне проекта.

Я мог бы пойти по пути не используя processEnv.getFiler(). CreateSourceFile (..) и просто создать исходные файлы java с помощью простого java-файла IO. Это было бы тривиально легко сделать, но я пытаюсь окрасить в линию, так сказать, и выполнять мои потребности в установленном порядке. Есть идеи ?

Answer 1

Я не думаю, что есть какой-либо специальный API для создания файлов для использования в других проектах. Что касается процессора (или даже Java в целом), то нет таких вещей, как «проекты» - известны только пути ввода и вывода, предоставленные компилятору.

Использование Filer и StandardLocation помогает с переносимостью процессора и позволяет не беспокоиться о структуре каталогов среды разработки. Если процессор будет использоваться только в этом одном проекте, такая мобильность не требуется и не должно быть вреда при использовании прямого файла io, поскольку вы точно знаете, как структурируются ваши модули.

Чтобы сделать это немного более идиоматичным, вы можете передать местоположения исходных каталогов другого проекта как compiler options в обработчик аннотации с опцией -Akey[=value]. Это, по крайней мере, приведет к предположению о структуре других проектов из вашего кода и перенесет ответственность за поддержание этих путей в инструмент построения. Maven лучше знает, как все проекты являются структурой, поэтому я думаю, что это было бы хорошим решением.