[
https://issues.apache.org/jira/browse/LABS-385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12734366#action_12734366
]
Simone Gianni commented on LABS-385:
------------------------------------
Testing Eclipse Galileo, AJDT version 2.0.0.e35x-20090624-1600 with AspectJ
version 1.6.5.20090618034232, m2e 0.9.8-200905041413 .
A few quick considerations :
- There is an option in AJDT configuration to "filter" some jars on the
aspectpath. This would allow to select which jars to use. Probably there is one
also for the inpath.
... Seems like the string to write here is "org.apache.magma", but I cannot
confirm right now if it is excluding other jars.
- Maven resolves workspace projects, AJDT seems to ignore them when
constructing the aspectpath. Disabling workspace resolution seems to make ITD
auto completion to work.
- Strangely enough, workspace projects aspects are correctly displayed in AJDT
in the cross reference view, but then ITD suggestions are not present, only
when jars are used they are there.
- If the workspace project is added directly from the AJDT interface, the
project stays there, but seems like if the maven one "takes precedence" and
situation does not change.
... Moreover, if the project is there added manually, AJDT behaves like if
aspects does not apply also with workspace resolution turned off.
- As always, a file using unclear ITDs is not marked as having an error in the
package view, but it is during editing, even if the cross reference view
displays that AJDT knows about the field.
- "third party" ITDs (situations where an aspect in A is adding methods on a
class in B and we are working in C having A and B as dependencies) are not
resolved if all jars are in the aspectpath, they are given as errors in the
editor but not in the package view.
- Adding all jars also to the inpath makes things extremely slow, and still doe
not resolve third party ITDs.
... All jars are unpacked and weaved in the target-eclipse/classes folder,
which takes a lot of time
..... Setting the "unreweavable" option reduces time
... Classes are correctly weaved with third party ITDs
... AJDT still does not see those ITDs
- Using -XterminateAfterCompilation basically removes all the AJDT features we
are searching for
With current configuration it is performing incremental builds of java files,
but still rebuilding (and reweaving) everything when it comes to modified
aspects, which is normal.
After a few rounds, Eclipse ran out of 512 mb of ram, and GC gave error. This
seems to be a memory leak (rebuilding was always the same). Anyway, 512Mb of
ram for the simple test project I was working on is really really too much.
> [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
