Comment 1 Adam Kiezun 2002-04-08 10:36:25 EDT

*** Bug 12991 has been marked as a duplicate of this bug. ***

Comment 2 Erich Gamma 2002-04-09 09:00:07 EDT

I suspect this is a consequence of the Jar element ambiguity, i.e., a JAR 
elements container is ambiguous since the JAR element is shared. 
 
The ambiguity could be resolved by an additional API that also takes the 
project containing the type as an argument. 

Moving to JDT CORE for investigation.

Comment 3 Jeff Badorek 2002-04-18 15:21:58 EDT

FYI...

I copied the source of HierarchyScope to my own class and added the following 
code to fix the bug for me. It seems to work OK so far.

public class FixedHierarchyScope ... {
   private IType parent;
   .
   .
   .
   public FixedHierarchyScope(IType type) throws JavaModelException {
      this.parent = type;
      .
      .
      .
   }

   private void buildResourceVector() throws JavaModelException {
      .
      .
      .
      paths.put(parent.getJavaProject().getPath(), parent);
      .
      .
      .
   }
}

Jeff

Comment 4 Jerome Lanneluc 2002-05-15 12:24:16 EDT

Jeff, do you still have the problem in a more recent build (ie. >= M5) and 
without your patch?

Comment 5 Geoff Longman 2002-05-15 12:34:12 EDT

Its seems to be ok in M5. Only had time for a very quick glance though. 

Comment 6 Jerome Lanneluc 2002-05-15 12:45:25 EDT

Ack and thanks for your prompt reply! 

Please reopen if you see the problem again.

Comment 7 Jeff Badorek 2002-05-15 14:34:33 EDT

I tested with M5 and still got "Could not uniquely map the type name to a type."

Here's the code I run...

	private IType chooseType(String base) {
		IPackageFragmentRoot root = getPackageFragmentRoot();
		if (root == null) {
			return null;
		}

		try {
			IType type =
				JavaModelUtil.findType(root.getJavaProject
(), "java.text.Format");
			IJavaSearchScope scope = new HierarchyScope(type);

			TypeSelectionDialog dialog =
				new TypeSelectionDialog(
					getShell(),
					getWizard().getContainer(),
					IJavaSearchConstants.CLASS,
					scope);
			dialog.setTitle("Open Type...");
			dialog.setMessage("Message...");

			if (dialog.open() == dialog.OK) {
				return (IType) dialog.getFirstResult();
			}
		} catch (Exception ex) {
			ex.printStackTrace();
		}

		return null;
	}


The dialog comes up just fine, but when I select a type and hit "Ok", I get the 
above error message.

Comment 8 Geoff Longman 2002-05-15 14:49:27 EDT

Just checked it again, works for me in M5 - code is as in my initial report

Comment 9 Jerome Lanneluc 2002-05-16 12:55:55 EDT

Jeff, do you have a test case that would show the problem? I guess it depends 
on the content of your workspace.

Comment 10 Geoff Longman 2002-07-19 09:24:36 EDT

I just found a case where this bug still occurs in 
build 200206271827
Win2k

To reproduce - start eclipse in a new workspace
create a new project - add a jar containing a hierachy of Types
In the source folders, ensure that there are absolutly not types that extends 
or implement any of the types in the jar file.

If a plugin were to execute the following:

IJavaSearchScope scope = SearchEngine.createHierarchyScope(myIType);

SelectionDialog dialog =
JavaUI.createTypeDialog(
    getShell(),
    new ProgressMonitorDialog(getShell()),
    scope(),
    IJavaElementSearchConstants.CONSIDER_CLASSES,
    false);

if (dialog.open .. yada yada.

where myIType is one in the jar file, then the Type Dialog will throw the 
original error.

I have debugged through this and it looks like HierachyScope's 
enclosingProjectsAndJarFiles collection is created wrong in this case as
org.eclipse.jdt.internal.corext.util.TypeInfo.findJarInScope() can't find the 
enclosing project as it is not in the scope.

If you take the same project and create a class in the source folders that 
implements or extends a type in the jar file - everything works fine.

Geoff

Comment 11 Geoff Longman 2002-08-05 13:15:28 EDT

Any word on this bug? Its very annoying and breaks my plugin.

Its been a couple of weeks since I re-opened the bug, and no response.

Comment 12 Martin Aeschlimann 2002-08-06 05:18:22 EDT

Both Jerome and Phillipe are currently in vacation. We have to wait until they 
are back...

Comment 13 Renaud Waldura 2002-09-28 18:40:45 EDT

I believe I ran into this a little while ago. The issue was kind of 
complicated, and I quickly found a workaround(*), so forgive me if I'm not 100% 
correct.

My recollection of what happens: TypeSelectionDialog.computeResult() attempts 
to find the IType for the selection. But if the selected type comes from an 
external JAR, it fails with the message given in the original report.

I traced it down to org.eclipse.jdt.internal.corext.util.TypeInfo line 176:

IPath curr= enclosedPaths[i];
if (curr.segmentCount() == 1) {

This "== 1" seems a little strange. Could Geoff Longman, the original reporter, 
check my explanation indeed applies to this problem?

(*) I subclassed TypeSelectionDialog and overrode computeResult() to skip the 
type resolution process entirely, since all I need is the type name.

Comment 14 Martin Aeschlimann 2002-09-30 03:56:05 EDT

(curr.segmentCount() == 1) is used to differ between projects and JARs. It 
fails if there is an external JAR with path length 1. Is that the case?
From the orignal description it sounds like a different problem.

There is a quite an ugly problem with paths for libraries as they can either 
map to an internal or external JAR and a heuristic has to be used to solve the 
ambiguity.
Jerome, is there API in JCore to solve this problem?

Comment 15 Jerome Lanneluc 2002-09-30 04:55:59 EDT

Sorry, there is no API. Please enter a separate feature request.

Comment 16 Renaud Waldura 2002-09-30 16:26:30 EDT

Martin, is (curr.segmentCount() == 1) the "official" heuristic used to 
differentiate between internal and external JARs? I ran into this problem too, 
IClasspathEntry.getPath returns a path relative to the workspace root directory 
for internal JARs, and an absolute path for external ones. I'm not sure how to 
tell the difference.

Comment 17 Martin Aeschlimann 2002-10-01 04:00:38 EDT

In this case the path can either be a project, external JAR and internal JAR.
curr.segmentCount() == 1 is used to test for a project. This, unfortunatly is 
only a guess. I filed bug 24245 for this.
A related problem is bug 24243.

However, I think this is not the problem of this bug report.
The problem is that scope.enclosingProjectsAndJars() does not contain the 
project where the JAR is located. TypeInfo assumes that it can find the JAR in 
one of the projects. This might be a wrong assumption as Geoff created the 
scope from a hierarchy. TypeInfo avoids the problem desribed in bug 24243 by 
using IJavaProject.findElement()
Having no project this fails. A method JavaCore.findElement(IPath) would solve 
the problem.
Or, even better: JCore takes over TypeInfo and TypeInfoRequestor

Comment 18 Renaud Waldura 2002-10-01 12:17:24 EDT

I think this is it. Martin nailed it on the head. The Hierarchy scope used by 
the dialog spans the entire workspace, while the type resolution that occurs 
once the dialog is dismissed doesn't. Hence the failure to resolve the type 
name. 

Comment 19 Martin Aeschlimann 2002-10-08 08:57:17 EDT

bug is in TypeInfo

Comment 20 Martin Aeschlimann 2002-10-08 10:35:44 EDT

fixed > 20021008

Comment 21 Geoff Longman 2003-10-19 12:35:52 EDT

So a year has gone by and I never had pressing need to verify that this bug was 
indeed fixed.

Its not.

I'm running the same code as I originally had the problem with.. there is no 
exception any more. yay!

However, the hierarchy scope search only shows types that exist in jars! No 
types in the source path are shown in the results.

This is in 2.1.1 running on Win2k.

Geoff

Comment 22 Martin Aeschlimann 2003-10-20 04:58:11 EDT

Geoff, I opened a new bug report 45193. Closing this one.