[
https://issues.apache.org/jira/browse/MCOMPILER-194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17798472#comment-17798472
]
Alexander Kriegisch edited comment on MCOMPILER-194 at 12/19/23 8:02 AM:
-------------------------------------------------------------------------
{quote}During the test run the {{AuditingEntityListenerIntegrationTest}} should
fail because of this (AspectJ based DI not taking place).
{quote}
[~oliver.gierke], I just looked into this, because I wanted to know if maybe it
could be an instance of [this Mojohaus AspectJ Maven (AJM)
issue|https://github.com/mojohaus/aspectj-maven-plugin/issues/15], which I have
fixed for the current snapshot of {{dev:aspectj:aspectj-maven-plugin}} (still
unfixed in Mojohaus):
I cloned [Spring Data JPA|https://github.com/spring-projects/spring-data-jpa],
because your reproducer is from an old 1.4 snapshot version of the product. In
a similar way, the problem is still reproducible today, if I comment out your
workaround {{<forceAjcCompile>true</forceAjcCompile>}} in the AJM config and
then run these two commands in sequence on the main branch:
{code:none}
mvn -pl spring-data-jpa clean test-compile surefire:test@integration-test
-Dtest=AuditingEntityListenerTests -Dsurefire.failIfNoSpecifiedTests=false
mvn -pl spring-data-jpa test-compile surefire:test@integration-test
-Dtest=AuditingEntityListenerTests -Dsurefire.failIfNoSpecifiedTests=false
{code}
*{color:#de350b}I cannot answer the question why MC thinks that anything has
changed and needs to be recompiled, even though the sources were not touched.
That is really a problem that needs to be solved in MC.{color}*
Regarding the interplay of MC and AJM, please be informed that the
configuration is not quite right on top of the original problem: The single
class you choose to compile with AJM...
{code:xml}
<includes>
<include>**/domain/support/AuditingEntityListener.java</include>
</includes>
{code}
is also compiled by MC, and your plugins are configured in such a way that MC
runs in an earlier phase than AJM. I.e., it is predictable that if MC
recompiles the file for whatever reason (e.g. because of the plugin bug here),
it will not be recompiled by AJM, because the latter correctly determines that
the source code is unchanged. Consequently, you will end up with a class file
without any woven aspect. But the same problem would manifest itself for other
Maven plugins relying on the (un-)changed status of source files and
disagreeing with MC, it is not an AspectJ problem per se.
Now what you can do instead of {{{}forceAjcCompile=true{}}}, is to actually
tell MC to exclude the same files(s) that you include in AJM:
{code:xml}
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<excludes>
<exclude>**/domain/support/AuditingEntityListener.java</exclude>
</excludes>
</configuration>
</plugin>
{code}
Now, you have clearly separated which plugin is meant to compile which classes,
and no class is unnecessarily compiled twice. As a side effect, the problem
caused by this MC bug here will go away, as now it is fine that AJM skips
compilation, because the target class is really unchanged. But atleast, MC does
not overwrite the class file anymore, even though it recompiles the other 177
source files. The MC bug still persists, but at least it does not annoy you
with regard to AJM anymore.
was (Author: kriegaex):
{quote}During the test run the {{AuditingEntityListenerIntegrationTest}} should
fail because of this (AspectJ based DI not taking place).
{quote}
[~oliver.gierke], I just looked into this, because I wanted to know if maybe it
could be an instance of [this Mojohaus AspectJ Maven (AJM)
issue|https://github.com/mojohaus/aspectj-maven-plugin/issues/15], which I have
fixed for the current snapshot of {{dev:aspectj:aspectj-maven-plugin}} (still
unfixed in Mojohaus):
I cloned [Spring Data JPA|https://github.com/spring-projects/spring-data-jpa],
because your reproducer is from an old 1.4 snapshot version of the product. In
a similar way, the problem is still reproducible today, if I comment out your
workaround {{<forceAjcCompile>true</forceAjcCompile>}} in the AJM config and
then run these two commands in sequence on the main branch:
{code:none}
mvn -pl spring-data-jpa clean test-compile surefire:test@integration-test
-Dtest=AuditingEntityListenerTests -Dsurefire.failIfNoSpecifiedTests=false
mvn -pl spring-data-jpa test-compile surefire:test@integration-test
-Dtest=AuditingEntityListenerTests -Dsurefire.failIfNoSpecifiedTests=false
{code}
*{color:#de350b}I cannot answer the question why MC thinks that anything has
changed and needs to be recompiled, even though the sources were not touched.
That is really a problem that needs to be solved in MC.{color}*
Regarding the interplay of MC and AJM, please be informed that the
configuration is not quite right on top of the original problem: The single
class you choose to compile with AJM...
{code:xml}
<includes>
<include>**/domain/support/AuditingEntityListener.java</include>
</includes>
{code}
is also compiled by MC, and your plugins are configured in such a way that MC
runs in an earlier phase than AJM. I.e., it is predictable that if MC
recompiles the file for whatever reason (e.g. because of the plugin bug here),
it will not be recompiled by AJM, because the latter correctly determines that
the source code is unchanged. Consequently, you will end up with a class file
without any woven aspect. But the same problem would manifest itself for other
Maven plugins relying on the (un-)changed status of source files and
disagreeing with MC, it is not an AspectJ problem per se.
Now what you can do instead of {{{}forceAjcCompile=true{}}}, is to actually
tell MC to exclude the same files(s) that you include in AJM:
{code:xml}
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<excludes>
<exclude>**/domain/support/AuditingEntityListener.java</exclude>
</excludes>
</configuration>
</plugin>
{code}
Now, you have clearly separated which plugin is meant to compile which classes,
and no class is unnecessarily compiled twice. As a side effect, the problem
caused by this MC bug here will go away, as now it is fine that AJM skips
compilation, because the target class is really unchanged. But atleast, MC does
not overwrite the class file anymore, even though it recompiles the other 177
source files. The MC bug still persists, but at least it does not annoy you
with regard to AJM anymore.
> Strange effects with springs @Configurable (AspectJ) and new compiler plugin
> version 3.0
> ----------------------------------------------------------------------------------------
>
> Key: MCOMPILER-194
> URL: https://issues.apache.org/jira/browse/MCOMPILER-194
> Project: Maven Compiler Plugin
> Issue Type: Bug
> Affects Versions: 3.0
> Environment: jdk 1.6.0_38, jdk 1.6.0_37
> Reporter: Andreas Höhmann
> Priority: Critical
> Attachments: MCOMPILER-194.zip, SO_AJ_MavenSoftExceptions.zip
>
>
> I have no details I can only report the "effects" ..
> I have a maven project with compiler-plugin 2.5.1,
> aspectj-plugin 1.4, java 1.6 and a lot of @Configurable
> annotations in my code. Aspectj will decorate these classes
> so @Autowired dependencies injected during runtime.
> All is working fine.
> Now I switch to compiler-plugin 3.0 ... nothing else changed!
> Then "sometimes" I got NPE's because the injected service etc. are
> not available. I guess aspectj was not successfull. I have no
> errors etc. anywhere during build.
> Strang :)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
