Dave,
thanks for your explanations. Basically our own findings support the
same view: the way the aspectj-maven plugin "pushes aside" the standard
java compiler plugin seems a bit hackish. Maybe Maven is lacking a
clear mechanism how to achieve such?
Anyway, my colleague Maxim Minin did come up with a similarly clever
hack to defeat the bad plain flat java compiler:
In our "master" POM.....
<pluginManagement>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>1.6</source>
<target>1.6</target>
<testExcludes>
<exclude>**/*.java</exclude>
<exclude>**/*.aj</exclude>
</testExcludes>
</configuration>
</plugin>
...
Thus the standard compiler will just not "see" any source files
anymore. This way he is free to compile whenever he feels like it
:-D
and doesn't interfere with the AspectJ compile anymore...
Dave Whittaker schrieb:
> At this point I've taken it a step further and I let Eclipse compile
> my Java/AJ code directly.... Of course you can't build outside of
> Eclipse that way, so if you are doing any type of continuous
> integration or other external build process it might not be
> appropriate for you.
yeah, exactly that's the problem for us. Basically this simple building
within the IDE and even by a compound of ANT scripts gets more and more
unmanageable. Thus we're more or less forced to build up something like
a Maven build, especially because in our environment (banking) there are
additional requirements of reproducibility of the artefacts creation.
Cheers,
Hermann
