Community
Participate
Working Groups
Using Eclipse F1 (same problem with M5), I have a problem with an external jar. I add an external jar to my project in the properties of it. No problem appears when the project is compiled. But, Eclipse always underlines objects, types, imports, ... that concern this external jar. For example, for an import, it writes 'import package cannot be resolved', but there no pb with the java compilator (in eclipse of course). This problem doesn't appear for every new project, but it always appears when Eclipse is configured to separate source and binary files. This must be done in the preferences of Eclipse, not when creating the new project. The problem appears neither with all jar files nor with "internal" jar files (not external jar files)
suspect that the reconciler reports incorrect problems in this case. Moving to JDT Core for investigation.
Damien - Could you supply this JAR ? Suspect it contains some entries which are fooling us when resolving anything against it.
Created attachment 1066 [details] Log4j jar file
Created attachment 1067 [details] Custom jar file (image management)
Sorry for answering so late. I attached both jar files which Eclipse is in trouble with. One is provided by the Apache Fundation, Log4J, and available here : http://jakarta.apache.org/log4j/docs/index.html The other is a custom jar file which manages a particular kind of images.
I cannot reproduce using the custom.jar file. I could import types from that jar (using it as an external jar) without any problem. Could you please submit a samble of code that points to the problem? Thanks.
It should be read "a sample of code" instead of "a samble of code".
It is very hard to reproduce the problem in a "clean" project. When I submitted the problem, there was a procedure that produced sometimes the problem. Today, that don't wanna "don't work" ;o) But for my complete project, it always appears if I use both files jar as external files if they are located INTO a subfolder of the project. If they are anywhere else, nothing happens. But i can't show this again in a new project. See the new attachment (17209.jpg) Can't do more, sorry.
Created attachment 1082 [details] Comparison between different situations
How did you create your external jars located in the subfolder without having the full path in the package view? When I tried, I got: d:/workspaces/test/P/lib/custom.jar displayed in the package view and not lib/custom.jar like in your comparison. I used the project properties to do it. Did you change manually the .classpath of your project?
> Did you change manually the .classpath of your project? Never ! I will try to be very precise. Here is an example of architecture : c:\ +-Eclipse\ | +... | +workspace\ | +-MyProject\ | +... | +lib\ | +jarOne.jar +-Z\ +jarTwo.jar So, there is 2 jar files, one in a subfolder of my project, on outside of my project. In the project properties, if i add jarOne as "add External JARs...", there is a problem (1st image). In .classpath, i get : <classpathentry kind="lib" path="C:/MyProject/lib/jarOne.jar"/> Eclipse shows just "lib/jarOne.jar" in packages view. In the project properties, if i ass jarTwo as "add External JARs...", there is no problem (2nd image). In .classpath, i get : <classpathentry kind="lib" path="C:/Z/jarTwo.jar"/> Eclipse shows "C:\Z\jarOne.jar" in packages view. In the project properties, if I add jarOne as "add JARs...", there is no problem (3rd image). In .classpath, I get : <classpathentry kind="lib" path="lib/jarOne.jar"/> Eclipse shows "lib/jarOne.jar" in packages view. I remind you that I created this project with a previous version of Eclipse, and if i try to reproduce the behavior on a new clean workspace, the problem doesn't appear. More, Eclipse always shows the full path for external jars (remember the 1st case, only relative path is showed). I think something is wrong somewhere in a configuration file, but I don't now what.
David - please investigate if this is a duplicate of bug 18190.
The log4j.jar which has been attached to this bug report is: Copyright (C) 1999 The Apache Software Foundation. All rights reserved. Any use of the logj4.jar is subject to the terms and conditions of the Apache Software License 1.1. More specifically: * 1. Redistributions of source code must retain the above copyright notice, * this list of conditions and the following disclaimer. * * 2. Redistributions in binary form must reproduce the above copyright notice, * this list of conditions and the following disclaimer in the documentation * and/or other materials provided with the distribution. * * 3. The end-user documentation included with the redistribution, if any, must * include the following acknowledgment: "This product includes software * developed by the Apache Software Foundation (http://www.apache.org/)." * Alternately, this acknowledgment may appear in the software itself, if * and wherever such third-party acknowledgments normally appear. * * 4. The names "log4j" and "Apache Software Foundation" must not be used to * endorse or promote products derived from this software without prior * written permission. For written permission, please contact * apache@apache.org. * * 5. Products derived from this software may not be called "Apache", nor may * "Apache" appear in their name, without prior written permission of the * Apache Software Foundation. * * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES, * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND * FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE * APACHE SOFTWARE FOUNDATION OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, * INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLU- * DING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS * OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
this is not a duplicate because there is only one project in this test case.
I can reproduce this bug with the following installation: C:\ +Eclipse\ | +... | +workspace\ +MyProject\ +src\ | +Test.java +bin\ +lib\ +foo.jar +p1\ +X.class Test.java : ----------------------------- import p1.*; public class Test { } ----------------------------- X.class : ----------------------------- package p1; public class X { } ----------------------------- With this workspace add foo.jar to MyProject as external jar. .classpath show this jar as external but package view show this jar as internal. The import statement is underlines but there is no problem with compilation.
To know if a jar is internal or external, the JavaModel use IContainer#findMember(IPath). With the previous test case ,this method should return null because the given path is absolute (C:\MyProject\lib\foo.jar). But findMember does not return null. /** * @see IContainer#findMember(IPath) */ public IResource findMember(IPath path, boolean phantom) { path = getFullPath().append(path); ResourceInfo info = workspace.getResourceInfo(path, phantom, false); return (info == null) ? null : workspace.newResource(path, info.getType ()); } The problem is that getFullPath().append(path) return '/MyProject/lib/foo.jar' with path='C:/MyProject/lib/foo.jar'. This new path is identical to the project relative path. That's why the result is not correct. Move to Platform/Core.
*** This bug has been marked as a duplicate of 10207 ***
