Community
Participate
Working Groups
When asking a java project whether a jar project resource is on the classpath, I pass in a project resource (/FooProject/WebContent/WEB-INF/lib/foo.jar), and it is compared to the same resource in the web app library container, only there it is absolutely named (C:/dev/workspaces/MyWorkspace/FooProject/WebContent/WEB-INF/lib/foo.jar). This is the exact same resource, but the workspace path is being compared to the absolute path. Can absolute paths not be used in both cases?
Jay, can you please investigate this ?
Could you please tell me how you added the jar file to the project (classpath) - whether as a project resource or as an external jar file? My observation is that when you add a library as an external jar to a project (even though it's inside the project) the absolute path is being used. On the other hand if you add the jar as a project resource, which is the recommended way, then this comparison failure should disappear.
In the particular scenario where I discovered this, I was using the "Web App Libraries" library container provided by WTP, wherein all jars that are added to the WebContent/WEB-INF/lib directory are automatically added to the library container. This is of course a WTP implementation. The external jars method is the easiest to reproduce from a pure-JDT standpoint. As an addition, I'd like to mention that these aren't *my* projects I'm dealing with here. If they were, it would be easy to use the recommended way you suggest. I'm dealing with user projects (I develop for WTP as well) and so I am required to use whatever setting the user has, whether it's recommended or not.
Hi Paul, I tried with a simple web application and could not reproduce the problem. This is what I did: 1. Created a simple dynamic web project. 2. Added few jar files to the WEB-INF folder. 3. Ensured that the jars were added to the 'Web App Libraries' 4. Open the 'Configure Build path' and open 'Web App Libraries' and ensure that the jar files are added with the workspace path and NOT absolute path. 5. Apart from this, I also stepped in to the JavaProject#isOnClasspath, I could find only the workspace paths being used. Please let me know if these are the right steps to reproduce the problem. Else, may I request you to provide me some test case, preferably the project with which you are finding the bug? -Jay
Alright, I misunderstood the problem statement. So, I guess what Paul wants is the ability to compare a relative path with an absolute path and vice versa. And this seems more like an enhancement to me. Jerome, can you please let me know your take on this one?
That's not *entirely* correct. My problem (among other things) is that I can't control whether I use a relative or absolute path. The project resource always has a relative path. The classpath entry *usually* has an absolute path. I iterate through jars in my project. Those resources are always relative paths. I ask "is this jar resource on the project classpath?" The framework returns false, because the classpath entry is using an absolute path for the jar. But in fact, the jar resource *is* on the project classpath. *It's the exact same jar.* Relative or absolute, this method is returning an incorrect answer. And I'm working on a test case but haven't completed it just yet, but I do not get the same results as Jayaprakash. The classpath entries for web app libraries use absolute paths.
Jay, one way to fix this issue would be to store a workspace relative path in the resolved classpath field (see PerProjectInfo) for paths that are given as absolute paths (either in the raw classpath or the container's classpath) but that are in fact relative.
Paul, I understand the issue better now. However, I would really like to have the test case that you mentioned. Though I can see the issue somewhat in the case of external jar files, they are not really same because your issue arises when you use classpath containers. So, please share the test case once ready.
Created attachment 138852 [details] test project This project is for use with the following test. Simply put in your JUnit target workspace and adjust the following: - the classpath entry for the external library jar should match your directory structure - add a classpath variable VARIABLE_LIB that points to the variableLib.jar - add a user library USER_LIB that includes the userLib.jar
Created attachment 138853 [details] junit test plugin Contains one JUnit test class: Test. My results: testSimple - pass testInternalJar - pass testExternalJar - fail testVariableJar - fail testUserLibraryJar - pass (I was surprised! But the user library setup figures out that the jar being added is an internal resource.) testWebAppLibJar - fail Note that while I did explicitly name the path to each jar in the tests, if I'd simply iterated through the project files to find the correct IFile, they'd be identical (or as identical as handles get).
Created attachment 139273 [details] Proposed patch Path includes a check to compare the absolute path of a resource when the classpath entry is an absolute path. Test cases included.
This patch works for my test cases, but I've uncovered a related issue (documented in bug 280497). We can treat these as separate issues if that's fine with JDT.
(In reply to comment #11) > Created an attachment (id=139273) [details] > Proposed patch > Path includes a check to compare the absolute path of a resource when the > classpath entry is an absolute path. Test cases included. Does org.eclipse.jdt.internal.core.JavaProject.isOnClasspathEntry(IPath, boolean, boolean, IClasspathEntry) need a similar change ? This is a private method that but gets called from public API method org.eclipse.jdt.internal.core.JavaProject.isOnClasspath(IJavaElement)
Created attachment 139944 [details] Modified patch Attaching the modified patch. The JavaProject#isOnClasspathEntry also needs similar fix.
Created attachment 139945 [details] Patch with updated tests Updated the patch after the fixes to the JavaProject#isOnClasspathEntry.
Released Jay's fix in HEAD for 3.6M1
This and bug 280497 are blocking one of our milestone targeted bugs. Can this fix possibly be moved to maintenance?
(In reply to comment #17) > This and bug 280497 are blocking one of our milestone targeted bugs. Can this > fix possibly be moved to maintenance? Olivier, what do you think ?
Blocking Dali JPA Tools is not an option. Please backport for 3.5.1. Reopening to get it fixed for 3.5.1.
Fix backported and released to R3_5_maintenance branch.
Verified for 3.6M1 using I20090802-2000
I have verified the fix for 3.6 M1 and 3.5 maintenance build M20090807-0800.
