Community
Participate
Working Groups
When a jar that is part of a java project is added to that project's classpath, the Package Explorer view suppresses the jar from being displayed at its original location in the file system tree. The same behavior is seen with class and source directories. While this behavior might be ok for classpath entries added manually, this behavior is bad when classpath entries are contributed automatically by a classpath container. WTP has a classpath container that automatically adds jars from web project's WEB-INF/lib directory to its classpath. As soon as a jar is dropped into the WEB-INF/lib directory it is picked up by the container. This makes it disappear from the original location in the Package Explorer view (drop target) leaving the users befuddled. Not only that, but once the jar has been added in order to delete the jar they have to switch to the Resource Navigator view. WTP has received at least half a dozen bugs reports pertaining to this behavior. Would it be possible to continue displaying resources at their original locations after they are added to the classpath?
*** Bug 141718 has been marked as a duplicate of this bug. ***
jdt core decides what resources are still shown as non-Java resources
What do you think Jerome ?
IMHO the current behaviour is ok, but there actually is a problem with JARs in WEB-INF/lib, because they can't be removed in any easy way, without using an external file editor to phisically remove the JARs from that folder in the file system.
I would like to see this addressed because of the impact on WTP, as described by the reporter, which Ive personally experienced.
This would require a new API: getNonJavaResources(int flags) where a flag would be INCLUDE_INTERNAL_JARS. Then the Package Explorer would need to use this new API.
Hmm, in I20080812-0800, I already see a differnce between Jars inside and Jars outside of the workspace: Jar stays in getNonJavaResources() if on classpath as: - kind="lib" path="<absolute-OS-path>" - kind="var" path="<VARIABLE>/<path-to-jar>" Jar suppressed in getNonJavaResources() if on classpath as: - kind="lib" path="<project-relative>" - kind="lib" path="<absolute-workspace-path>" - kind="con" path="org.eclipse.jdt.USER_LIBRARY/<user-lib-name>" (stored as absolute workspace path) I guess WTP could work around the issue by adding the jars to their container using an absolute filesystem path, and not with a relative path inside the workspace. That being said, I don't think we should add another preference for the user to toggle the appearance. What's the reason for suppressing the Jars from getNonJavaResources() at all? On the top level, it would look strange if the Jar would appear as a resource and also as a package fragment root (as siblings). On the other hand, I don't think it would be a problem to *always* leave a Jar in getNonJavaResources() if its resource is not a direct child of the project (e.g the /<project>/WEB-INF/lib case). > [..] once the jar has been added in order to > delete the jar they have to switch to the Resource Navigator view. In the Package Explorer, I can delete a Jar from the workspace via Edit > Delete, even if it is on the build path. I would expect this to work with the web tools container as well (at least in 3.4).
> I guess WTP could work around the issue by adding the jars to their container > using an absolute filesystem path, and not with a relative path inside the > workspace. Interesting. This does work. I will go ahead and put this workaround into WTP. Could you indicate whether this behavior is considered a bug that would be fixed at some point or something that's likely to continue unchanged. > That being said, I don't think we should add another preference for the user to > toggle the appearance. What's the reason for suppressing the Jars from > getNonJavaResources() at all? On the top level, it would look strange if the > Jar would appear as a resource and also as a package fragment root (as > siblings). On the other hand, I don't think it would be a problem to *always* > leave a Jar in getNonJavaResources() if its resource is not a direct child of > the project (e.g the /<project>/WEB-INF/lib case). I think it's possible to go a bit further than that. Even if a jar is at project root, there is still no possibility for user confusion if the jar is being added by a classpath container. The only case where confusion can happen is when a jar is at project root and is added to classpath directly. If you do go with this approach, in the case where original entry is suppressed, you need to make sure that the possible actions on the visible entries are a union of what's possible on the classpath entry and what's possible on a regular file. To be specific, the Delete action needs to work. There may be others. > > [..] once the jar has been added in order to delete the jar they have > > to switch to the Resource Navigator view. > > In the Package Explorer, I can delete a Jar from the workspace via Edit > > Delete, even if it is on the build path. I would expect this to work with the > web tools container as well (at least in 3.4). You can't do that if the original file is suppressed. The Delete action for jar classpath entries is disabled. It looks like it is disabled even for stand-alone jar entries (not sure why). For containers, enabling the Delete action would require new API in order to delegate to container implementation.
OK, the Delete action is currently only available for Jars on the classpath that are directly inside the project, but not e.g. for Jars in WEB-INF/lib or for Jars from other projects.
(In reply to comment #7) > Jar stays in getNonJavaResources() if on classpath as: > - kind="lib" path="<absolute-OS-path>" > - kind="var" path="<VARIABLE>/<path-to-jar>" Entered bug 244406 for these cases.
For the problem reported in comment 0, the 'WEB-INF' directory is expanded by the Package Explorer, not by JDT/Core. Moving to JDT/UI to remove the filtering of jars on the classpath in non-Java directories.
OK, the plan is to show Jars as normal files (i.e. without children) at their original location, with one exception: If the Jar is - directly inside the project, - directly on the classpath, and - the "Referenced Libraries" node is not shown, the Jar file is suppressed and only the package fragment root is shown. I'm not yet sure what to do about the Delete action. It certainly needs to be available on the classpath entry in case the Jar is suppressed. We could also enable it for all classpath entries whose resource is inside the classpath entry's project. In the second case, it should then also work on entries in WTP's classpath container (no support from the classpath container needed).
The workaround suggested to WTP to fix this problem is breaking a consuming product. In the mean time, WTP has agreed to revert that fix but we will need a proper fix from JDT as soon as possible.
Created attachment 129501 [details] Fix Implements comment 12. I didn't touch the Delete action, so it is still only available on Jars whose resource is a direct child of the project. But for the WTP case, Jars can now be deleted from the lib folder (since their resource stays visible there).
Jerome, I'm ready to release together with bug 244406.
Released to HEAD.
Verified in I20090428-0100 but it also does this for source folders which get the library decoration. This is confusing. Filed bug 274023 to track this.
*** Bug 307219 has been marked as a duplicate of this bug. ***
