Community
Participate
Working Groups
Steps to reproduce: - Create an AspectJ project - Add a jar (say, spring-aspects.jar) to the project's classpath - In the AspectJ Build, "Aspect Path" tab, click "Add JARs" -> It doesn't offer the jars from the classpath to be added to aspect path. This forces using "Add External JARs" leading to hard-coded paths being referred from the project. AJDT version: 1.6.1.200810152052
Interesting... Not able to reproduce this on my machine. I still see jars in the Add Jar dialogue even if they are on the project's classpath. The dialogue is a standard dialogue that is borrowed from JDT. I wonder if this has something to do with the eclipse version. I am currently running Eclipse 3.4.0. You?
Also, a way to get around this problem (for now) would be to edit the .classpath file directly. Just add the aspect path attribute to the existing classpath entry. Like this: <classpathentry kind="lib" path="output.jar"> <attributes> <attribute name="org.eclipse.ajdt.aspectpath" value="org.eclipse.ajdt.aspectpath"/> </attributes> </classpathentry>
I am using Eclipse 3.4.0 (through STS 1.1). I see jar files from another open project, but not from the same project. Furthermore, I see jars from only one of the two open projects. Weird.
Thanks for reporting. I'll look into this.
OK. Able to reproduce it on 1.6.1.200810152052, but it is not happening in the ;atest from head. A new development version that contains this fix should be out tomorrow (Oct 21). It is likely that this will be the RC for AJDT 1.6.1.
This bug should be a duplicate of 251111.
Ramnivas, the fix has gone out in the Relase Candidate (available from the 3.4 dev update site: http://download.eclipse.org/tools/ajdt/34/update). Please let me know if this fix works for you.
I checked with 1.6.1.200810222003 and I still see the problem. It seems that the dialog shows the jar files only from direct or indirect subdirectories of the project's root in any open project. It doesn't, however, show jar files from "Referenced Library" (which are outside of the project, referenced through a variable). I checked the normal "Java Build Path" and that shows the same behavior -- referenced libraries do not show. However, this is expected, since in the same project all the referenced libraries are by definition already on the classpath. For AspectJ, since a referenced library doesn't imply being on the aspectpath, referenced jars should be available for selection.
OK. Now I understand what you are talking about. The jar in question is part of a classpath container and the classpath container is already on the build path. You want the capability to add individual jars in the container to the aspect path, but not the entire container. This will requre a bit of design work because it falls outside the scope of how classpath entries are typically used. This issue has already been discussed in bug 251278. (It is *not* a duplicate of bug 251111 as I had originally thought.)
Rereading comment #8, I realize that you may not be talking about a classpath *container*, but a classpath *variable*. Am I understanding correctly?
(In reply to comment #10) > Rereading comment #8, I realize that you may not be talking about a classpath > *container*, but a classpath *variable*. Am I understanding correctly? > Correct. For example, If I have two jars on a project's classpath: M2_REPO/foo.jar and M2_REPO/bar.jar (where M2_REPO is a variable pointing to a location outside the project), I will like to have an option to add either of the entries to aspectpath.
Thanks for the clarification. I am trying to understand your workflow so I can recreate your problem. Here is what I m doing, but I can't seem to find a problem with it: 1. in an aspect project's java build properties page libraries tab 2. choose add variable 3. select JUNIT_HOME 4. click extend... 5. choose junit.jar 6. click on AspectJ Build 7. select Aspect Path tab 8. click add variable 9. select JUNIT_HOME 10. click extend... ----- At this point, I still see junit.jar as something I can select. My understanding is that you are not seeing it. Am I correct? --- 11. choose junit.jar 12. And now junit.jar is successfully on the aspect path. Please explain if there is something I am missing.
(In reply to comment #12) Thanks Andrew for looking into this. The first 7 steps are the same. Let me explain the next few steps I am trying: > 1. in an aspect project's java build properties page libraries tab > 2. choose add variable > 3. select JUNIT_HOME > 4. click extend... > 5. choose junit.jar > 6. click on AspectJ Build > 7. select Aspect Path tab 8. Click on "Add JARs" (not "Add Variable") 9. See JUNIT_HOME/junit.jar and click on it 10.JUNIT_HOME/junit.jar becomes a part of the aspectpath
Now that I understand what you are doing, I can recreate your exact problem. If a jar in the workspace is on the project's classpath by way of a classpath variable, then it is not available to add to the aspect path or in path by way of "add jar". And adding the jar via "add external jar" will create a duplicate classpath element error. To a certain extent, this is by design. We do not want duplicate elements on the classpath (which is what would happen if the jar is added to the aspect path via "add jar"). However, using "Add variable" instead of "add jar" will properly add the jar to your aspect path. Is there a reason why this is not working for you?
I see your point. This issue originated through a project created by Maven, where the classpath entries are updated by Maven (but, unfortunately, not aspectpath entries). So it feels convenient to not have to go through "add variable" and use an existing classpath component. As for the duplicate entries, I would expect duplicate entries to be automatically filtered i.e. when adding to aspectpath, if the same entry in classpath exists, no duplicate will be added. For non-Maven projects, a more convenient will be to first add to aspectpath and as a result automatically get added to classpath. So this issue won't surface there. Since this seems like issue with a specific use case (which would be best fixed by the Maven plugin), I think this is minor severity feature.
(In reply to comment #15) > For non-Maven projects, a more convenient will be to first add to aspectpath > and as a result automatically get added to classpath. So this issue won't > surface there. Yes, this *is* the way it already happens. When something is added to the aspect/in path, it is also automatically added to the build path. It seems to me that the real problem is the lack of coordination between maven and ajdt. Maven controls a project's classpath, but you must control the aspect path. It would be nice if maven could also control what gets placed on the aspect and in paths. I imagine that this could be through some marker in the pom.xml.
Just an update on this cause I'm using Maven without support for AJDT. In the AJDT 2.0.0 version I can add the entire Maven classpath container, and then filter which jars I want to be added, both to classpath and inpath. This is still a bit of a pain, but here are the steps. 1. Expand the maven classpath container in the package view 2. Right click on a jar inside it 3. Select AspectJ tools -> add to (aspectpath|inpath) 4. Right click again and select AspectJ tools -> Configure AspectJ build path 4b. Get there from project properties if you like moving your mouse more :) 5. Go to aspectpath/inpath 6. Expand the just added classpath container 7. Click on "Only the following elements ..." 8. Click on "Edit..." 9. Type your filters Also, the "AP" decoration will appear on all jars in the classpath container, and projects eventually in the classpath container does not work correctly (maybe separate issues could be filled for these two problems). In my opinion it would be great to have a button to add to the aspectpath or inpath an element already in the classpath of the project, cause this issue affects everyone using Maven, Ivy, or any other tool that will fill the classpath for you. We can't expect them all to support AspectJ and AJDT.
Bug 271338, Bug 279488, Bug 273770, Bug 124460 (AspectJ bug) are all somewhat related to flexibility of the in path and aspect path. We recognize that there is a need to have a more flexible way of specifying the elements on those paths, one that is not tied to JDT's .classpath. Currently, Aspect path and in path are specified as classpath attributes on certain classpath entries in the the java (aspectj) project's classpath. This is great because it allows us to piggy-back on JDT's validation and storage of classpath entries. It is also a concise way of specifying elements. However, because of being tied to the classpath, it becomes impossible to specify elements that are not on the classpath (or at least not on the raw classpath (eg, inside a classpath container)). It would be a fairly major rewrite to rip this piece of AJDT out and provide a new mechanism for specifying, validating, and storing the in path and aspect path. This is something I would like to see, however. I just don't know when I will be able to have time to do it.
Hi Andrew, (now) I do understand the limitations of the AspectJ model. Holding that true until another solution is found however, the AJDT UI could ease the pain of placing on the inpath/aspectpath only some of the jars already on the classpath of the project. The "Add to aspectpath" and "Add to inpath" menu options already do this extremely well for regular classpath entries. They could be accessible from the property page aswell, either extending the "Add jar" or adding a "Add jar from classpath". The same actions could behave differently when applied to a classpath container. For example, instead of adding the whole container, they could a) See on which container child the action was invoked on, add the entire container if not already present, add the name of the child jar to the filter b) Open a dialog where the user selects the child jars to add, and compose the filter string accodingly. Right now the functionality is there, it is just a bit hard to get to it and have it behave correctly.
I have just committed a feature enhancement that will help address the issues raised here. See bug 279488 for a description of what this enhancement is.
First bug listed in c18 should be Bug 271388, not 271338.
