[
https://issues.apache.org/jira/browse/LABS-385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12734569#action_12734569
]
Simone Gianni commented on LABS-385:
------------------------------------
After an exaustive mail exchange with Andrew Eisenberg, main committer of AJDT,
and some experiments and digging in the code, it seems like the solution is not
in binary weaving.
In fact, unfortunately, "the model exposed to AJDT [by AspectJ] does not
contain the target [of an ITD or aspect] if that is a binary file". As a
consequence, there is no way AJDT can be aware of additions performed on jar
files on the in path, no matter if these additions arrive from the current
project, an external jar or whatever else.
The limitation is not in AJDT however, it is just in the fact that they are
binary.
Currently in Magma ITDs are mostly used between magma project. Just a very
small of modifications are executed on external libraries. In any case, both
for Magma and external libraries, they are all open source, and most of them
have source on Maven.
The user could have the need to weave a non-magma library (for example legacy
code), but also in that case will most probably have sources to attach to the
jar.
I tried using linked source folders, containing the source of the jars, and
giving that information to AJDT it is able to properly resolve all ITDs and
checks.
Unfortunately, AJDT will in that case also weave all dependant jars for which
sources are linked (technically, they become part of the project itself). While
this is a waste of time, it is actually carried out incrementally, so it does
not affect the main use cases of LABS-281, that involves modifying methods
inside WebHandlers.
Linked source folders also have a few other abilities :
- They can be read only
- They can be configured to send output to an alternate output folder
- They could be hidden from the package tree view using a custom filter and a
naming convention
Unfortunately they does not support "jar source folders" instead of plain
source folders, so sources need to be unpacked.
AJDT has a long term plan for exposing also binary targets, and more generally
to have AJDT use a lighter approach to checking and information gathering,
using only the matching part of AspectJ instead of complete compile and weaving.
I proposed for AJDT to overcome the problem in the short term by exploiting the
source attachment. In the mean while an eclipse plugin for magma that does
exactly this (creates a linked source folders unzipping source attachments
found by maven, and sets up a filter to hide them to the user).
> [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
