Critical Description
AspectJ scans all loaded class to see if they match aspects. To properly inspect a class, it needs to resolve a number of things, especially parent class and implemented interfaces.
It happens quite often that a class is not completely resolvable. For example, many packages include bridging classes to external libraries, like to logging systems, but does not DEPEND strongly on those libraries, instead they are optional dependencies, and proper logic is in place to avoid calling those bridge classes if the library is not there. AspectJ is not aware of this logic, and fails trying to resolve those bridge classes, throwing AbortExceptions.
To avoid this AbortExceptions to actually stop the build (and the developer run) process, Magma catches these exception.
This however causes real problems when there IS actually a good reason for that exception to be thrown. For example, the user could declare a certain bean to implement a certain inferface from an aspect, and then fail to provide implementations for all methods in the interface.
In this case, AspectJ will throw an AbortException, Magma will catch it and keep on going, no aspect will be applied to that specific class, so the "bare bone" class will be used, causing then problems during runtime. These problems are extremely hard to debug, cause apparently no error is given.
Also, due to the -XterminateAfterCompile AspectJ switch that Magma uses to reduce coupling between packages, some of the bare bone classes are not completely valid or usable as they are, they need AspectJ weaving to resolve some parts. A typical situation is the JVM throwing VerifyError regarding the stack size of methods, which means that the bare bone class is being used and so probably an AbortException has been thrown.
There should be a way to discern, once such AbortExceptions are caught, wether they are ignorable (like Velocity depending on Log4j) or if they must really stop the cycle and notify the user of a real severe problem.