Community
Participate
Working Groups
Proposal pasted from the following email discussion: http://dev.eclipse.org/mhonarc/lists/ajdt-dev/msg00379.html We finally seem to be both have more support for working directly with the Java Model, and more need to do so. Here's an idea for a light-weight update to our architecture that will give us transparent access for working with the relationship map using either the IJavaElements or IProgramElements. The idea is that we change the handle identifiers, used for storing entries in the map, to be the same those used by the JavaModel, i.e. IJavaElement.getHandleIdentifier(). That will allow us to ask for relationships for IJavaElements, and get back a list of handles that an adapter can turn into IJavaElements. Currently our identifiers are a source location including path, line, and column number. The Java model uses the handles that look like the following, "=Project-l/src<pkg1{Foo.java[Foo~m1", which uniquely identify members, are stable across builds and Eclipse invocations, but don't go below the member signature. So our adapter will have to extend these by appending either line/column or offset information to reach at "code" elements (e.g. calls, handlers). That's doable, and these handles should just get ignored by JavaCore as desired. But I'm wondering what they should correspond to in our extended Java Model, perhaps a subtype of SourceRefElement called ICodeElement? We should get JDT Core to add something like that anyway, but they'll probably want to call it IUnknownElement or IGenericRefElement to provide other projects with the same sort of extensibility. Another challenge will be generating the project part of the handle because our compiler doesn't know about workspaces. I hope that info can be extracted from the full path and source path information. Then for other IDEs we can simply use the same relative path convention.
I've addressed this by allowing IDE clients to provide their own mechanism for creating ASM handles. For AJDT to add a new that handles JavaCore style handles do the following: 1) Implement org.aspectj.asm.IElementHandleProvider and provide the four methods that map source location information to handles. 2) Somewhere in the plugin initialization call: AsmManager.getDefault().setHandleProvider(..) Doing (1) depends on being able to map source locations to IJavaElement.getHandleIdentifier() strings. If that turns out to be a pain to do in a way that performs we can consider changing the AspectJElementHierarchy to not realy on line number information and instead do lookups based on member names.
It appears from Mik's comment as of April that this request should be closed out in the AspectJ database.
Yes, the ASM part of this is now there. I'm not sure if AJDT is actually using a custom handle provider though, or whether it is still doing that translation step.
