Community
Participate
Working Groups
The Organize Imports feature of Eclipse doesn't work on libraries which were included as "external Jars". When I start OI it deletes all imports which would come from an library included as "external Jar". OI works fine with libs which were included as Jar relative to the projectpath.
After some research I discovered that the problem only occurs when the libs reside on a network drive.
it should not make a difference whether a lib is on a network drive or not. Philippe can you see how this could happen?
Olivier - pls investigate
Would you have a test case I can try to reproduce the problem? On what platform are you running Eclipse? Did you use symbolic links? Please give me as many details as possible to reproduce this defect. Thanks.
I cannot reproduce under Windows2000. Could you please give more details on your settings? A test case would be very welcome.
Michael - can you provide some reproduceable steps ? It works fine for us.
Hi, sure, I wrote Olivier today. So I'm sorry, I can't provide a test case. I'm running Windows 2k Pro geman with all hotfixes from the WindowsUpdate. I have a network share on: D:\Eigene Dateien\Projekte (rw to everyone). Now I connect a network drive (z:\) to my own machine (\\jakl\projekte) - this is the working directory for eclipse. ("eclipse.exe -data z:\") Now I start a new project: Create new Java Project. Sourcefolder: "src" and outputfolder: "classes". Now I create an folder "lib". I copy some libs to this folder (with the Windows Explorer). After this I add an "External Jar" from the Project Properties/Libraries dialog. (I see this line: "webmacro.jar - Z:TestForEclipse/lib" maybe is there a missing slash?) Then I tried to create a new class and wanted to extend WMServlet, but it wasn't in there. (Obviously it's not a bug in Organize Imports than in the general function to read the libs) I also tried log4j.jar an it worked fine on a small (new) project, but on an larger project this one didn't work either. Webmacro.jar didn't work on both projects. I hope this helps a little, if you need more information or you could give me some hints how to provide a better bugreport please feel free to contact me. I'm sorry but I'm not familiar with JUnit. Kind regards, Michael
I reproduced the problem, I think. It fails only if the working directory is directly a drive name. For example, eclipse -data d:\ fails, but eclipse -data d:\workspace works fine. d:\ is a network drive in this case. I have some problem to debug it, because d:\ is not considered as a valid working directory in the lanching configuration. I guess it should be, which means this is another problem. I will investigate this problem. Could you please try on your machine with a working directory like z:\workspace and let me know if it works. I am trying to isolate the problem and it would help if it works for you as well. Thanks for your help.
The problem is really related to the fact that the workspace is created in the root folder of the network drive. It might be the same for a local drive. I will double check that.
I can reproduce a similar problem using a local drive. If I start eclipse with: -data c:\ and I follow the following steps, Organize imports... doesn't work properly. 1) Create a new project P 2) Set 'src' as a source folder for P 3) Create a folder lib in the root of P. 4) Add a jar inside this folder using the Windows Explorer. 5) Refresh from local this folder. You should see the jar file. 6) Add this jar as a external jar to your project classpath. 7) Create a new class in the default package of P and write code that refers to a class inside the jar without qualifying the class name. For example instead of p1.B, write simply: B. 8) Run organize imports. It won't add an import for the class in your jar. 9) Now remove the jar and add it again as an internal jar. 10) Now run again "Organize imports" and it works, but the import is underlined and it is said: "The import .... cannot be resolved". So there is a second problem here. The code compiles fine. If Eclipse is started with a folder in the -data options, all problems are gone.
I hacked the pde.ui launchers in order to be able to start a debug workspace on c:\. The problem with the external jar pointing to a local file in the workspace is that the NameLookup doesn't find the corresponding package fragment root and therefore it cannot retrieve any package fragments or types which are located inside this jar. I need to investigate what is wrong when the package fragment root is created.
We have an inconsistency between the resolved classpath, which considers the jar package fragment root with its absolute path (for example c:\P\lib\myLib.jar) and the path of the jar package fragment root itself, which is considered as a local resource and therefore its path is /P/lib/myLib.jar. Then the openWhenClosed() method on PackageFragmentRoot failed to open this jar package fragment root because it is not considered on the project's classpath even if this is the case. So we need to understand how we got into this inconsistent state.
In fact I wonder why an external jar can point to a jar inside the workspace. By definition, this is not an external jar and I would expect the wizard to complain about it.
According to your comment (2002-06-11 14:31). I tried to put the workspace into an directory, and everything worked fine. Thanks for your efforts.
This would be a consequence of using IContainer#findMember(IPath). This API removes any device from the argument path, and transforms it into a relative path.
This is a known problem with the findMember API. Defer 2.0.
Reopening
Clearing resolution
We should consider improving on this front: 1- ensure all jdt/core calls are going through JavaModel#getTarget 2- improve JavaModel#getTarget to better deal with such situations.
Changed all relevant call to findMember in Java Model to use getTarget instead. Fixed getTarget to consider that a path with a device can only be an external path.
Verified.
