Javac + Lombok 阶段后如何使用 AspectJ Maven 进行二进制编织

Question

我有一个使用编译方面并在编译时编织它们的项目。我想添加 Lombok，但不幸的是 Lombok 不支持 AJC。由于该项目本身没有任何方面的来源，因此在使用 Javac+Lombok 编译后，我将 AspectJ Maven 插件配置为进行编译后编织。

这是 AspectJ Maven 插件的配置：

<forceAjcCompile>true</forceAjcCompile>
<sources/>
<weaveDirectory>${project.build.outputDirectory}</weaveDirectory>

它在 Maven Compiler 插件编译后立即附加到编译阶段。这样 Lombok + Javac 将首先被调用，然后 AJC 将在 Javac 生成的类文件上执行编织。

在 javac 生成的类上执行字节码编织时是否有任何限制/缺点？

也许有更好的方法可以让 Maven+Lombok+Aspects+Idea 一起工作而不会出现问题。

这是一个最小的示例项目：https : //github.com/Psimage/aspectj-and-lombok

Answer 1

在另一个问题中，您在评论中问我时，我实际上认为您的方法有问题，但它确实有效。为了直接从 IDE (IntelliJ IDEA) 运行测试，我唯一需要做的就是将应用程序和测试运行器实际委托给 Maven，否则 IDEA 不会同时应用 Lombok + AspectJ。

如果您的方法有效，请使用它。但实际上 AspectJ Maven 建议了另一种方法：首先使用 Maven 编译器编译到另一个输出目录，然后将该目录用作 AspectJ 编译器的编织目录。但是，那里的示例 POM 不能 100% 工作，因为在命令行上为 Javac 指定输出目录时，该目录需要存在，编译器不会创建它。所以你也需要一些丑陋的 Antrun 动作：

<plugins>

  <plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-antrun-plugin</artifactId>
    <version>1.8</version>
    <executions>
      <execution>
        <id>unwovenClassesFolder</id>
        <phase>generate-resources</phase>
        <configuration>
          <tasks>
            <delete dir="${project.build.directory}/unwoven-classes"/>
            <mkdir dir="${project.build.directory}/unwoven-classes"/>
          </tasks>
        </configuration>
        <goals>
          <goal>run</goal>
        </goals>
      </execution>
    </executions>
  </plugin>

  <plugin>
    <artifactId>maven-compiler-plugin</artifactId>
    <executions>
      <execution>
        <!-- Modifying output directory of default compile because non-weaved classes must be stored
             in separate folder to not confuse ajc by reweaving already woven classes (which leads to
             to ajc error message like "bad weaverState.Kind: -115") -->
        <id>default-compile</id>
        <configuration>
          <compilerArgs>
            <arg>-d</arg>
            <arg>${project.build.directory}/unwoven-classes</arg>
          </compilerArgs>
        </configuration>
      </execution>
    </executions>
  </plugin>

  <plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>aspectj-maven-plugin</artifactId>
    <configuration>
      <aspectLibraries>
        <aspectLibrary>
          <groupId>me.yarosbug</groupId>
          <artifactId>aspects</artifactId>
        </aspectLibrary>
      </aspectLibraries>

      <forceAjcCompile>true</forceAjcCompile>
      <sources/>
      <weaveDirectories>
        <weaveDirectory>${project.build.directory}/unwoven-classes</weaveDirectory>
      </weaveDirectories>
    </configuration>
    <executions>
      <execution>
        <phase>process-classes</phase>
        <goals>
          <goal>compile</goal>
        </goals>
      </execution>
    </executions>
  </plugin>

  <plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <version>2.22.2</version>
  </plugin>

</plugins>

我建议另一种方法作为替代：

1. 创建一个非编织的 Java 模块，在那里做 Java + Lombok 的东西。
2. 为 AspectJ 二进制编织创建一个单独的模块，使用 Java 模块作为编织依赖项。因为您的单元测试同时依赖于 Lombok 和 AspectJ，所以将测试放在这个模块中。

优点是你不需要摆弄多个编译器、执行阶段、输出目录、Antrun 等。

更新：

我克隆了你的 GitHub MCVE，这个在 branch master上的提交 反映了我在上面的示例 XML 中解释的内容。

我还创建了一个带有另一个提交的分支多阶段编译，它根据我的替代想法有效地重构了项目。我只是引用提交消息：

Multi-phase compilation: 1. Java + Lombok, 2. AspectJ binary weaving

There are many changes (sorry, I should have split them into multiple
commits):
  - Marker annotation renamed to @marker and moved to separate module
    because the main application should not depend on the aspect module.
    Rather both application and aspect now depend on a common module.
  - New module "main-app-aspectj" does only AspectJ binary weaving on
    the already lomboked Java application.
  - Both application modules have slightly different unit tests now: One
    checks that Lombok has been applied and AspectJ has not, the other
    checks that both have been applied.
  - Aspect pointcut limits matching to "execution(* *(..))" in order to
    avoid also matching "call()" joinpoints.

The end result is that now we have a clear separation of concerns, clear
dependencies, no more scripted Ant build components and the new option
to use the lomboked code optionally with or without aspects applied
because both types or JARs are created during the build.

随意将我的 fork 作为另一个远程添加到您的 Git 存储库，并从那里提取我的更改。如果您希望我向您发送拉取请求以使其更容易，请告诉我。