labs-labs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Simone Gianni (JIRA)" <j...@apache.org>
Subject [jira] Resolved: (LABS-385) [build] Investigate the eclipse project setup optimal for Magma project
Date Wed, 05 Aug 2009 01:04:14 GMT

     [ https://issues.apache.org/jira/browse/LABS-385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Simone Gianni resolved LABS-385.
--------------------------------

    Resolution: Fixed

> [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
>            Assignee: Simone Gianni
>             Fix For: Current
>
>
> 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-unsubscribe@labs.apache.org
For additional commands, e-mail: labs-help@labs.apache.org


Mime
View raw message