Ошибка при компиляции при использовании компилятора AspectJ вместо Javac
У меня есть проект с несколькими модулями. В настоящее время этот аспект добавляется к "основному" проекту. При выполнении mvn clean install
здесь он работает. Однако, пытаясь выполнить mvn clean install
в родительском проекте, с этой ошибкой сбой возникает при компиляции одного из других проектов:
Тип org.hibernate.annotations.CacheConcurrencyStrategy не может быть разрешен. Это косвенно ссылается на требуемые файлы .class
Если я добавлю также зависимость ядра Hibernate в этом проекте, это тоже работает, но добавление зависимостей к проектам, которые не должны иметь зависимости, не имеет смысла, поэтому это не решение. При компиляции с javac
он отлично работает.
В чем причина? И как я могу исправить это, поэтому я могу использовать компилятор AspectJ без утечки зависимостей к проектам, которые не должны иметь этого?
У меня есть эта конфигурация в родительском POM:
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>aspectj-maven-plugin</artifactId>
<version>1.5</version>
<configuration>
<source>1.6</source>
<target>1.6</target>
<complianceLevel>1.6</complianceLevel>
</configuration>
<executions>
<execution>
<goals>
<goal>compile</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
Обновление
Я только что узнал. Выполнение mvn clean install
прерывается каждый раз. Однако при запуске mvn [clean] install
одно время прерывается. Затем работает mvn install
без clean
. Я вижу, что builddef.lst
в целевой папке - причина, по которой она работает, и не работает на основе того, запускаете ли вы чистую. Итак, теперь мой вопрос: как вы автоматически создаете этот файл?
Родительский POM файл:
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.mycompany</groupId>
<artifactId>core-lib</artifactId>
<name>core-lib</name>
<packaging>pom</packaging>
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>aspectj-maven-plugin</artifactId>
<version>1.5</version>
<configuration>
<source>1.6</source>
<target>1.6</target>
<complianceLevel>1.6</complianceLevel>
</configuration>
<executions>
<execution>
<goals>
<goal>compile</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
<dependencies>
<dependency>
<groupId>org.aspectj</groupId>
<artifactId>aspectjrt</artifactId>
<version>1.7.4</version>
</dependency>
</dependencies>
<modules>
<module>core-xyz</module>
<module>core-xyz2</module>
</modules>
</project>
Ответы
Ответ 1
Включить отладку при вызове maven, чтобы копать глубже. Вы должны заметить, что компиляция aspectj только вызывается во время первого вызова maven с помощью clean. Поскольку builddef.lst уже существует после первого вызова, вызов без очистки пропускает компиляцию aspectj.
Этот аспектj компилирует поведение плагина ранее и был описан здесь:
http://out-println.blogspot.com/2007/08/compile-time-checks-with-aspectj-part-2.html?m=1
Вам нужно будет глубже изучить основную проблему, но, как уже сказал один комментатор, компилятор aspectj должен быть включен только в модули, которые этого требуют.
В противном случае необходимы дополнительные зависимости для компиляции aspectj, как вы уже заметили. Я включил aspectj компилировать в свою собственную работу без проблем, ограничив ее только теми модулями, которые этого требуют.
Ответ 2
В соответствии с AspectJ компилятор Maven плагин вы можете настроить argumentFileName
для поиска существующего builddef.lst
.
Итак, вы можете сгенерировать builddef.lst
и скопировать его в свою папку ресурсов и проинструктировать плагин AspectJ Maven для использования этого файла.