Community
Participate
Working Groups
203 1. new worksace, use jdk1.2.2 as JRE 2. create project xxx 3. get project org.eclipse.swt 4. to project xxx add swt.jar 5. open all types: Composit. Only awt composite, but not swt I have a saved (small) workspace, in case this is not reproducable. I struggle with problems like this since yeserday, it must be a regression.
Could not reproduce. Can you send me your workspace?
workspace sent by mail (8MB) All types workes when you add the JRE to the swt project. But: 1. Create a class A in XXX. 2. Type 'Composite', select 3. Add import. No swt-Composite 4. When you debug you see that search for types does not contain it. (AddImportOnSelectionAction.java, findAllTypes)
Yes, now I can reproduce. The orignal steps could not fail because the search was done on the whole workspace. The problem with AddImportOnSelectionAction is that it searches in a search scope that contains only the project XXX. If you want to find matches in the swt.jar (which is not part of the project), then you need to explicitely add it. Note that before (not sure when this changed), the search scope was wrongly adding all the prerequesites of the project for free. Now the rule is the following: if a project is included in the search scope, only its source folders, the jars internal to the project and its external jars are added for free. Jars that are contained in other projects must be included explicitely. I just updated the specifications of SearchEngine.createJavaSearchScope (IResource[]) Moving to JDT UI.
When you remove JRE_LIB from the swt project, The all types dialog does not contain the SWT-Composite. How about that? This is a workspace-scoped search.
On the search scope there is a method 'setIncludesClasspaths' Setting to true does not change anything. It is not specified by the documentation what is the default setting of this flag. From looking at the code, it was true.
You didn't specify that swt.jar was not included in the classpath of org.eclipse.swt either. (it's hard to guess :-) In this case, I see the problem: the workbench scope doesn't include swt.jar. I will fix this. However this won't fix your second problem (ie. with AddImportOnSelectionAction) Moving back to JDT Core.
I think you have to resolve the classpath. What should the method IJavaSearchScope.setIncludesClasspaths mean then? If you really decide to have the user put in the paths from the class path, please offer a method createJavaScope(IJavaProject project, boolean includeClasspath)
Having looked at our code I see that we use the JavaSearchScope at around 10 places with the idea that you get types visible by a class path: Type selection dialog in wizards, search in refactorings... I vote to keep the original behavoir.
Will add createJavaScope(IJavaProject project, boolean includesClasspaths) If includesClasspaths is true, then everything that is visible by the project will be added for free. In other words, the project, its source folders, its jars (internal or external), the referenced projects, and recursively the referenced projects' source folders, jars, etc. will be added to the search scope. If includesClasspaths is false, then only the project will be added to the search scope. In other words, its source folders, its jars, and the referenced projects won't be added for free. Please, let me know if this is what you want.
After more talking with Martin and Philippe, made the following change: SearchEngine.createJavaSearchScope(IResource[]) has been deprecated. Use SearchEngine.createJavaSearchScope(IJavaElement[]) instead. The rational is that createJavaSearchScope(IResource[]) was not well defined for projects, and it could not define a search scope for java elements that didn't have a corresponding resource (e.g. external jars). The specification of createJavaSearchScope(IJavaElement[]) is as follows: - If an element is an IJavaProject, then the project's source folders, its jars (external and internal) and its references projects (with their source folders and jars, recursively) will be included. - If an element is an IPackageFragmentRoot, then only the package fragments of this package fragment root will be included. - If an element is an IPackageFragment, then only the compilation unit and class files of this package fragment will be included. Subpackages will NOT be included. This fixes the second test case. The worspace scope that was used in the original test case has also been fixed to include everything in the workspace.
