Community
Participate
Working Groups
Using eclipse 3.4 and ajdt 1.6.0.200808060124, adding AspectJCorePreferences.ASPECTPATH_ATTRIBUTE attribute to entries of custom classpath container (m2e "maven dependencies" to be specific) does not seem to add the entries to project aspect path, according to AspectJ Build properties in UI at least. This works as expected in AJDT 1.5.2.200804241330, so it looks like a regression in 1.6.0.200808060124.
How do you add the aspect path attribute to the container? Are you doing this programmatically, through the UI, or by editing the .classpath file?
The attribute is added programmatically to the entries of Maven classpath container. Here is simplified code <code> Set<IClasspathEntry> entries = new Set ...; ArrayList<IClasspathAttribute> attributes = new ArrayList ... attributes,add(AspectJCorePreferences.ASPECTPATH_ATTRIBUTE); ... entries.add(JavaCore.newLibraryEntry(entryPath, // srcPath, srcRoot, new IAccessRule[0], // attributes.toArray(new IClasspathAttribute[attributes.size()]), // false /*not exported*/)); ... IClasspathContainer container = new MavenClasspathContainer(path, entries); JavaCore.setClasspathContainer(container.getPath(), new IJavaProject[] {javaProject}, new IClasspathContainer[] {container}, monitor); </code>
OK. After this code is executed, does the attribute appear the .classpath file?
No, like for all classpath containers .classpath has a record for container itself but not container content (this is the point of classpath containers). As I mentioned in original report, this exact code works with AJDT 1.5.2 and used to work with earlier 1.6.0 builds, so I am 100% sure that the attribute is properly associated with classpath entries inside the container.
Getting closer...does this happen for all classpath entries in the container or just for project entries? If the answer is yes, then I will have a patch for you by the end of the day. If not, then I will have to dig a little more. To get around this issue, you can also add the apsect path attribute directly to the MavenClasspathContainer.
Let me be more clear on that last sentence: In order for the Classpath Container to appear in the aspect path UI, it *must* contain the aspect path attribute (same for the in path attribute). If the container contains the aspect/in path attribute then all classpath entries it contains will as well. Having a classpath container where only some elements have the aspect/in path attribute is not something that we have tested for.
We set the attribute for some entries in the container. We do not set the attribute for the container itself. The problem occurs for library entries. We need support for project entries too. I have not explicitly tested project entries yet, but will do it as soon as library entries work again.
Created attachment 109439 [details] patch that checks inside a classpath container for classpath entries on the in/aspect path This patch will add entries inside of a classpath container to the in/aspect path if the entry has the appropriate attribute. Note that the classpath container itself will not appear in the UI as being on the aspect/in path. To do this, the attribute must be added to the container itself (and hence labelling every contained entry as being on the aspect/in path). Frankly, I'm surprised this worked in previous versions of AJDT because this is something that we have never tested for to my knowledge. Andy, please commit this to both the AJDT 1.5 and AJDT 1.6 streams. Igor, after it is commited please update to the latest dev version of 1.6 and see if this properly addresses your problem.
committed to AJDT1.6 - dont have a 1.5 around right now to put it in, will get to it...
fix in AJDT 1.5 now too
Igor, Is this patch working for you? Let us know and we can close the bug.
Sorry, I was down with the flu last days, will try to validate the fix today.
Created attachment 109729 [details] sample plugin, includes sources
Created attachment 109730 [details] workspace expected by the samply plugin
Unfortunately, this still does not work with 1.6.0.200808071509. I've attached sample plugin (with sources) and workspace projects that demonstrate the problem. The only "interesting" class in the sample plugin is ajcontainer.actions.ConfigureContainerJob. The job can be invoked from UI (Sample Menu/Sample Action) and it has hardcoded referenced to the projects from the sample workspace. The job creates "Sample Container" on project named "b" and adds one project and one jar entry to the container. Both entries have AspectJCorePreferences.ASPECTPATH_ATTRIBUTE. After importing the sample projects into a fresh workspace and invoking ConfigureContainerJob, I can see that new "Sample Container" is added to project "b", however aspect path of the project is empty. Expected result is to have two separate aspect path entries, one for the jar, another for the project. Let me know if you need more details. PS: I think I left some debug calls to AspectJCorePreferences.getResolvedProjectAspectPath in ConfigureContainerJob. Please disregard, m2e does not use nor need to use getResolvedProjectAspectPath.
Created attachment 109799 [details] patch to AspectJCorePreferences.java Fixes the trouble with getting aspect paths out of containers. Thanks for the test case, Igor. This patch should fix your problem. Andy, please commit to 1.5 and 16 stream.
Created attachment 109806 [details] New patch...this time with test case I made a test case out of the plugin and workspace you sent me. This patch overrides the previous one.
Patch for core preferences source file wont apply, neither this recent version or the older one without the testcase in. Given the trauma we are having with patches recently I wonder if we have a bug with creating patches against AspectJ projects.
altho... I just looked at merging it by hand and it seemed to contain some stuff I had already put in from a patch yesterday. Did you definetly completely synchronize AspectJCorePreferences and have no incoming/clashing changes before creating the patch?
patch forced in - will be in next dev build of ajdt1.6
ok - so it does appear per the chat we had just now that the patch was created at the 1.5 level. I guess I assumed that as the bug was raised against AJDT 1.6.0 that the patch would be primarily for that level but something worth backporting. It also looks like the patch includes changes for another bug (autobuild bug) that weren't already backported - as that is still open. But I've committed this into 1.5 now too. will just need to remember that the autobuild patch will clash when trying to commit that into 1.5
Igor, Please let us know if this patch works for you. We want to make sure this is fixed for the AJDT 1.6.0 release coming up shortly. Hope you are over your flu.
I am sorry to say this, but I still cannot make AJDT work with entries from classpath containers. Fresh e34 "classic" with AJDT 1.6.0.200808151716. I ran the test steps I explained in the comment #15 and do not see neither jar nor project in Aspect Path UI.
This is surprising behavior to me. And it seems a little strange that previous versions of AJDT would put things in the aspect path UI that are not directly on the path. The previous patches ensure that the entries with the appropriate classpath attribute are placed on the appropriate in/aspect path. But, it does not put them in the UI. So, the entries are on the path, but they don't appear in the UI (just as other entries in classpath containers do not appear in the UI). I will look to see what previous versions of AJDT did and see if it makes sense to recreate this behavior.
I tested this in AJDT 1.5.1 and early development versions of 1.5.3 (couldn't get easy access to a version of 1.5.2). In both cases, looking at the Aspect path properties page gives an infinite loop and an out of memory error. This confirmed my suspicion that if the behavior you have seen does work in earlier versions of AJDT, it was because of a fluke rather than because it was designed to behave that way. I did a major refactoring of how aspect and in paths are handled for 1.5.3. In the past, the raw classpath and the resolved classpath were being mixed in incorrect ways. Additionally, projects could not be placed on the aspect or in paths. So, I do not want to regress to previous behavior. If the above behavior had worked and it would have been possible to view aspect path path entries in containers, and the programmer removed the aspect path entry from the dialog, the resulting classpath/aspect path would have been inconsistent. Not good. Here is my solution. When displaying aspect/in paths, the UI will also peek inside of containers and display any entries inside of them, but these entries will not be able to be removed (perhaps a warning dialog will appear telling the programmer which container contributed them).
But this solution raises another question: Should exported aspect/in path entries on projects in the classpath also be included in the UI and in the Project's aspect path? eg- Project A has Project B on its classpath. Project B has Jar C on its aspect path and exports it. Should Jar C be on Project A's aspect path? (Note that Jar C is already on Project A's classpath.) For now, I am going to say no. I don't have any other reason other than it is difficult to implement and it seems like an obscure case, but I am willing to implement this if someone requests this functionality.
Created attachment 110510 [details] Patch to add aspect/in path elements to the UI This patch adds aspect/in path elements from containers to the Aspect Build Path properties page. Now, you will be able to see these elements in the UI. You will not be able to remove them, but there is a child node attached to each element specifying which container provides that element. Andy, please commit to the 1.6 stream and Igor please let me know if this works for you. This should be the final patch. Once Andy
I have committed the patch. However it seems to have left me with errors (it applied fine). My workspace no longer compiles with errors about isAspectPathAttribute() and isInPathAttribute() not being defined on AspectJCorePreferences. And they aren't from what i see in my workspace. From a cursory glance through the patch they don't seem to be added by it. It also seems to contain the beginnings of changes for the extraneous element map rebuilds when working with multiple projects - did you mean to include that?
Created attachment 110581 [details] Fixing compile error in last patch For some reason, the two files of this patch weren't included in the last one. If you submit this patch, the build should be fixed.
comment 29 patch in
I checked 1.6.0.200808211329 and although I did not have much time to play with it, ajdt appears to properly add to aspect path both library and project entries (whoohoo!). Thank you very much for your help and I think this bug can be closed now.
Glad to hear it is working. (Finally!) Please come back here if you notice any more problems.
Quick question, when do you expect ajdt 1.5.x build that includes this feature?
If Andrew confirms which patch will work on 1.5 (does the most recent include everything required?) then i can put it straight in.
There have been so many patches lately that I need to check what's already in 1.5. Some of the functionality is there, but not all of it.
The change is in the 1.5 stream now. Andy, please close this bug as fixed.
fixed in AJDT 1.5 and 1.6, wooo
