Community
Participate
Working Groups
Build ID: I20080502-0100 Steps To Reproduce: 1. Create as Aspect source in a package few levels deep (a.b.c.d) 2. Try using a class from another library (and package). I used org.apache.log4j.Logger 3. Eclipse updates the source file with an 'import org.apache.log4j.Logger', BUT its place before the 'package' declaration. More information: AJDT Version : 1.6.0.200805141703 AspectJ version: 1.6.1.20080514120000
Hi, I would like to take a shot at solving this. I did some investigation over the weekend; it seems the organize imports operation uses the standard JDT APIs. I am speculating the same is used by the Java editor as well. But I am still missing a piece in puzzle - why is the AST being updated differently in case of an *.aj editor?
Feel free to take a stab at it and submit a patch. See bug 10659 for a similar issue. In this case, a Java parser is being used to parse the file, but since it is an aspect file, the file cannot be parsed. The import is placed at the beginning of the file because the operation doesn't know where else to place it. I'd look into this possibility first. Submit another comment if you'd like me to clarify.
(In reply to comment #2) > Feel free to take a stab at it and submit a patch. > See bug 10659 for a similar issue. In this case, a Java parser is being used > to parse the file, but since it is an aspect file, the file cannot be parsed. > The import is placed at the beginning of the file because the operation doesn't > know where else to place it. > I'd look into this possibility first. Submit another comment if you'd like me > to clarify. Right. So, the ASTParser needs to be extended to parse AspectJ sources, correct?
I haven't actually looked into this problem yet, but that's my guess based on the description. If this is the reason for the bug, then it is something we will be looking into for AJDT 1.6.x.
we have an Aj enabled AST parser, I thought the problem here was that we could not get to the point in the JDT code where it chooses a parser, so we could not tell it to use ours rather than the java one?
That's right, Andy. My point was that if we do decide to go ahead with weaving, we will need to plug the AJ parser into the Java parser hierarchy in the right place. So that in effect we are extending the Java parser.
A search for ASTParser (for .java) in my workspace reveals quite a few places where the ASTParser is being instantiated and used (Editor, refactoring operations etc). It seems to me that it might be an idea to abstract away the ASTParser behind an interface so the implementations can be switched transparently. But that might imply touching JDT sources as well. Thoughts?
Modifying the JDT to introduce a suitable point for extension and making the AST pluggable is a good way to try and proceed. JDT don't usually take our extensions so worst case we may move to binary weaving the JDT to introduce the extension point. It could get a little messy as the AspectJ AST parser is not guaranteed to return the same entities as the regular JDT parser (I haven't looked) - but in some places we have our org.aspectj.* prefixed forms of JDT types. In which case we may need to translate them into what the invoker of the AST parser wants.
> See bug 10659 for a similar issue. Meant to say bug 106589
*** Bug 242475 has been marked as a duplicate of this bug. ***
Probably addressed by JDT-weaving. Will look into this.
Yep. Will create a test for this.
Test has been committed.
