[
https://issues.apache.org/jira/browse/LABS-385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12734092#action_12734092
]
Simone Gianni commented on LABS-385:
------------------------------------
This issue is connected with LABS-281, cause once AJDT + m2eclipse do a good
job at incrementally compiling and weaving classes inside eclipse, those
classes could be used by a realoding classloader inside the running jetty.
> [build] Investigate the eclipse project setup optimal for Magma project
> -----------------------------------------------------------------------
>
> Key: LABS-385
> URL: https://issues.apache.org/jira/browse/LABS-385
> Project: Labs
> Issue Type: Improvement
> Components: Magma
> Reporter: Simone Gianni
> Fix For: Next
>
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: labs-unsubscr...@labs.apache.org
For additional commands, e-mail: labs-h...@labs.apache.org
