Как использовать AspectJ Maven для двоичного переплетения после фазы Javac + Lombok

Когда вы задали мне другой вопрос в комментарии, я действительно подумал, что у вас проблемы с вашим подходом, но он работает. Единственное, что мне нужно было сделать, чтобы запустить тест непосредственно из 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 и т. Д.

Обновление:

Я клонировал ваш MCVE на GitHub и эта фиксация в ветке 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.