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 _______________________________________________ aspectj-users mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/aspectj-users
