« Return to Thread: State of the AspectJ/Java editor?
Re: State of the AspectJ/Java editor?
by Johan Fabry
::
Rate this Message:
Hi Andrew, all,
I have a question related to this: I'm doing some code analysis,
related to cross-cutting report plugin that I was working on
previously. I'm talking to Eclipse using its standard API, getting
information from all the ICompilationUnit elements that I can access.
There's a problem however, related to these red squiggles on valid
code, which admittedly may be due to my setup (see below). The problem
is that if the base code references (eg. does a method call of) an
ITD, the ICompilationUnit for that class is not available. I suppose
this is because the code does not compile using standard Java.
I am using some external package to access the ICompilationUnits,
which actually has a headless eclipse running in the background and
talking to that instance. I suppose this is an eclipse that does not
have AJDT loaded. If I would hack the package to ensure that eclipse
loads AJDT (which I would like to avoid at all costs), will this solve
my problem? (BTW Is there a way to 'manually' load a plugin by talking
to this headless eclipse?). If having AJDT loaded does not solve the
problem, is there another way?
Thanks in advance!
On 07 Jul 2009, at 17:53, Andrew Eisenberg wrote:
> Hi David,
>
> Our goal is to ensure that spurious AspectJ errors (ie- red squiggles
> on valid code) are not seen at all (but this has to be weighed against
> being to aggressive and ignoring actual errors). We have taken care
> to ensure that the common uses of AspectJ syntax will not show red
> squiggles in the editor, but more advanced uses of aspectj (such as
> generic ITDs, especially those on interfaces) have been less well
> tested.
>
> There is no explicit documentation that describes what is working and
> what is not, but there are a slew of test cases for this and the code
> for this is well documented. At this point, if you are seeing
> something in the editor being marked as a problem when the compiler
> thinks it isn't, please let us know and we will address it as soon as
> we can.
>
> For the past little while, we have been waiting to hear from users
> when they come across some of these spurious errors. And we fix them
> as they come in. The best way to help me debug this is to send some
> examples of failing code. You can raise a bug if you like, or you can
> send it through this mailing list.
>
> --a
--
Johan Fabry
jfabry@... - http://dcc.uchile.cl/~jfabry
PLEIAD Lab - Computer Science Department (DCC) - University of Chile
_______________________________________________
aspectj-users mailing list
aspectj-users@...
https://dev.eclipse.org/mailman/listinfo/aspectj-users
I have a question related to this: I'm doing some code analysis,
related to cross-cutting report plugin that I was working on
previously. I'm talking to Eclipse using its standard API, getting
information from all the ICompilationUnit elements that I can access.
There's a problem however, related to these red squiggles on valid
code, which admittedly may be due to my setup (see below). The problem
is that if the base code references (eg. does a method call of) an
ITD, the ICompilationUnit for that class is not available. I suppose
this is because the code does not compile using standard Java.
I am using some external package to access the ICompilationUnits,
which actually has a headless eclipse running in the background and
talking to that instance. I suppose this is an eclipse that does not
have AJDT loaded. If I would hack the package to ensure that eclipse
loads AJDT (which I would like to avoid at all costs), will this solve
my problem? (BTW Is there a way to 'manually' load a plugin by talking
to this headless eclipse?). If having AJDT loaded does not solve the
problem, is there another way?
Thanks in advance!
On 07 Jul 2009, at 17:53, Andrew Eisenberg wrote:
> Hi David,
>
> Our goal is to ensure that spurious AspectJ errors (ie- red squiggles
> on valid code) are not seen at all (but this has to be weighed against
> being to aggressive and ignoring actual errors). We have taken care
> to ensure that the common uses of AspectJ syntax will not show red
> squiggles in the editor, but more advanced uses of aspectj (such as
> generic ITDs, especially those on interfaces) have been less well
> tested.
>
> There is no explicit documentation that describes what is working and
> what is not, but there are a slew of test cases for this and the code
> for this is well documented. At this point, if you are seeing
> something in the editor being marked as a problem when the compiler
> thinks it isn't, please let us know and we will address it as soon as
> we can.
>
> For the past little while, we have been waiting to hear from users
> when they come across some of these spurious errors. And we fix them
> as they come in. The best way to help me debug this is to send some
> examples of failing code. You can raise a bug if you like, or you can
> send it through this mailing list.
>
> --a
--
Johan Fabry
jfabry@... - http://dcc.uchile.cl/~jfabry
PLEIAD Lab - Computer Science Department (DCC) - University of Chile
_______________________________________________
aspectj-users mailing list
aspectj-users@...
https://dev.eclipse.org/mailman/listinfo/aspectj-users
« Return to Thread: State of the AspectJ/Java editor?
| Free embeddable forum powered by Nabble | Forum Help |
