如何让java注释处理器从projectA读取和处理注释，并为projectB生成java源文件

Question

我创建了一个java注释，它将我的一些“服务”类标记为服务，然后编写一个注释处理器，生成相应的servicerequest和servicehandler类。 这适用于GWT maven项目，其中服务请求被发送到服务器到中央调度程序以由各种服务处理。

我的maven项目由一个父项目和5个子模块项目组成。

项目结构是这样的：

• MoodleMobile （父母maven项目）
  • gwtMoodleWS （GWT层）
  • moodleBuildSupport （包含注释处理器）
  • moodleGeneratedServiceHandlers （生成的类的所需位置）
  • moodleWS （服务器端层）
  • moodleWSAPI （注释处理器将运行的代码的位置）

我的问题是这个。

让注释处理器从一个项目（moodleWSAPI）读取和处理注释并在另一个项目中生成java源文件（moodleGeneratedServiceHandlers）的规定方法是什么？

我似乎有许多注释处理器的例子，它们为运行注释处理器的同一个项目生成java源文件，但不适用于不同的项目。

我已经成功构建并测试了我的注释处理器，但我无法弄清楚如何让它生成处理器运行的项目之外的文件。目前它在moodleWSAPI中生成java源文件（这是错误的） 。 我希望它处理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（）规范中没有看到任何允许我指定项目外部输出的内容。

我可以走不使用processingEnv.getFiler（）。createSourceFile（..）的路线，只使用简单的java文件IO构建java源文件。 这很容易做到，但我想在线条内着色，可以说，并按照规定的方式完成我的需要。 有任何想法吗 ？

Answer 1

我认为没有任何特殊的API可用于创建用于其他项目的文件。 就处理器而言（或者甚至是Java），没有诸如“项目”之类的东西 - 只有已经提供给编译器的输入和输出路径是已知的。

使用Filer和StandardLocation有助于处理器的可移植性，并避免担心开发环境的目录结构。 如果处理器仅用于这个单一项目，那么这种可移植性并不是真正需要的，并且使用直接文件io应该没有任何危害，因为您确切知道模块的结构。

为了使这更具惯用性，您可以使用-Akey[=value]选项将其他项目的源目录的位置作为编译器选项传递给注释处理器。 这至少会使您对代码中的其他项目结构产生任何假设，并将责任转移到维护构建工具的路径上。 Maven最了解项目的结构，所以我认为这将是一个很好的解决方案。