Community
Participate
Working Groups
When a package import cannot be resolved, Eclipse highlights only a portion of the package, as well as displays only a portion of the package in the error view. It appears that Eclipse is doing a search of package segments, and only highlights up to the last segment it looked for. This seems like an implementation detail that is bleeding through to users. Test Case: (1) Create a java project named Test (2) Create a class named Test (3) Add the import "import org.eclipse.ui.*;” (4) The editor only highlights "org.eclipse" and the error reported is "The import org.eclipse cannot be resolved" This situation creates a real headache for developers because they cannot simply look at the error view to see what they need to add to their class path (or manifest file). Instead, they must actually open each source file and look at the imported packages to figure out what real packages they are missing.
We do not agree. When a package reference such as a.b.c.* cannot be resolved, we prefer to know that a.b is missing. It helps issolate the problem to which jars are not included on the classpath.
Re: "It helps isolate the problem to which jars are not included on the classpath." I'm a little confused on this point. How does this help to isolate anything? The package name that you chose does not have to correspond to jars at all. I argue that the error message "The import org cannot be resolved" does not isolate the problem as much as "The import org.eclipse.ui.actions cannot be resolved". By only showing a portion of the needed package, a user doesn't really know what to add to fix the breakage without physically opening the java source file. It seems to me, going out of your way to mask the real error, doesn't isolate the problem, but adds to it.
Kent, could you please comment ?
It helps most users because they are not faced with 100's of slightly different missing package errors which are all caused by the same problem - a missing jar that includes all of those packages.
Thanks for the explanation. However, I still disagree. If all the imports that are not resolved lived in one jar, it might help. But what about if I have something like: import org.eclipse.core.runtime.IPath; import org.eclipse.core.runtime.IStatus; import org.eclipse.jface.dialogs.Dialog; import org.swt.widgets.Button; This results in four of the exact same error messages: "The import org.eclipse cannot be resolved". However, the code lives in three different jars. What this means is that to figure out the real package that is missing, I must inspect the source code. If my project has a lot of source, this would result in a tedious task of trial and error. If the real package were displayed in the task view, I could display the task view, and open the project properties to add the necessary jars to the classpath, referring back to the task view to know which ones to add… To really do what you proposed in the explanation above, you would really need to report the error based on the last unique package segment. Meaning, the above imports would cause the following errors: The import org.eclipse.core cannot be resolved The import org.eclipse.core cannot be resolved The import org.eclipse.jface cannot be resolved The import org.eclipse.swt cannot be resolved I still don't believe that this is perfect either, as the error message still does not display the real error. But it is better than simply telling me that it couldn't find 'org.eclipse' which is way too vague to be of any use. But for now, I'll just agree to disagree. Thanks again...
