Community
Participate
Working Groups
Create a Web Project Create a library under WebContent that uses a resolved include path entry. Add some new files with types in sub folders of your library folder. Types added do not get indexed and are not found in search or content assist.
Created attachment 169548 [details] patch Uses the resolved include path entries to build PackageFragmentRoots. JDT only allowed raw entries because it did not expect source files inside a library in the project, but that is allowed in JSDT.
Created attachment 169908 [details] Updated patch
* Explain why you believe this is a stop-ship defect. Or, if it is a "hotbug" (requested by an adopter) please document it as such. If the JavaScript Include Path for a project contained .js files inside the project using a Include Path Container or a Library, they wouldn't be included in the Index or Search results. * Is there a work-around? If so, why do you believe the work-around is insufficient? No workaround. * How has the fix been tested? Is there a test case attached to the bugzilla record? Has a JUnit Test been added? Tested by debugging. * Give a brief technical overview. Who has reviewed this fix? When determining if a source file was on the include path, if it was inside of a container or library, the raw include path was used instead of the resolved include path. That meant that the path to those source files would be prefix-checked against the encoded container path, such as org.eclipse.wst.jsdt.launching/favoriteWebToolkit, instead of an actual in-workspace path such as Projectname/web-toolkit. Files not judged to be on the Include Path don't have their contents stored in our index, so they'd never show up in our search results. * What is the risk associated with this fix? Low. The errant code is a leftover from JDT treating .class files and .java files differently.
Patch applied.
