Major Description
Currently a magma project is seen by eclipse as :
- A Maven project
- An AspectJ project
Maven builds the classpath for the project, placing all the dependency jars in it.
AspectJ however have three distinct "classpaths". One is called "aspectpath" and is where to find aspects to apply to the current project and to jar in the "inpath". The "inpath" contains jar to which aspects of the current project and the "aspectpath" apply. the other is the common classpath.
There "three way" distinction is aimed at offering better performances when AspectJ compiles, but is somehow difficult for a user to get used to it. So, in Magma, everything containing an aop.xml or aop-ajc.xml file is placed on the aspectpath, and everything else on the inpath.
This happens during maven builds and magma:run LTW, but does not happen inside eclipse. Infact there are two kind of problems :
- Eclipse see the entire "Maven dependencies" classpath entry as more or less monolithic, at least it is not possible to configure which single jars go on the aspectpath from the user interface, maybe it's possible to do it programmatically.
- Placing everything on the aspectpath, partially solves the problem, because it makes AspectJ markers appear in your project, but does not resolve ITDs correctly (which are vital for Magma) cause does not apply them to the target classes.
- Placing everything also on the inpath requires way too much RAM (at least last time i tested it), eclipse starts hogging the CPU for a few minutes until GC refuses to keep that load and the compilation fails.
We should examine a way to setup a magma project correctly, eventually extending the eclipse:eclipse maven plugin, or writing a "magma project nature" for eclipse, able to apply in eclipse the same situation found in the maven build, so that eclipse AJDT plugin can offer the user proper interface while writing Magma classes.
It would be enormously helpful if AspectJ (AJDT specifically) provided a way to set a "check only" path, that does not actually perform complete compilation, but is used only to check :
- If a pointcut applies
- If there is an ITD
- If that ITD applies correctly
- If there is a precedence problem
While these informations require more or less a complete build to be produced, still not writing the entire weaved inpath to files would save quite a bit of system resources, taking for granted that is not eclipse in charge of producing the final build, but some external tool (LTW eventually) that will then handle the situation correctly.