Summary: | Util#getJavaLikeExtensions doesn't consider Java-like content types | ||||||
---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Matt Chapman <mpchapman> | ||||
Component: | Core | Assignee: | Jerome Lanneluc <jerome_lanneluc> | ||||
Status: | VERIFIED FIXED | QA Contact: | |||||
Severity: | normal | ||||||
Priority: | P3 | CC: | daniel_megert, eclipse | ||||
Version: | 3.2 | ||||||
Target Milestone: | 3.2 M5 | ||||||
Hardware: | PC | ||||||
OS: | Windows XP | ||||||
Whiteboard: | |||||||
Attachments: |
|
Description
Matt Chapman
2005-12-21 06:26:24 EST
Created attachment 32088 [details]
suggested fix
here is my suggested fix
Makes sense to me. Rafael, is it in the philosophy of the content type support for a plugin A to consider content types defined by other plugins and based on plugin A's content type ? The hierarchy of content types follows the same principles of OO: if something applies to a content type, it applies to any content type derived from it as well. The content type framework provides means for you to figure out whether the content type of a resource (for instance, AspectJ) is a kind of your content type of interest (for instance, Java). But if I remember correctly, you guys are not requesting the content type of a file to be provided, and doing the matching yourselves. Thus, you have to do something similar to what is suggested here. Taking only the patch as reference (I didn't look at the rest of the code in Util.java), there is a problem: it will only take immediate children into account, ignoring any children at deeper levels. To avoid that, the for loop could be changed to: for (int i = 0; i < contentTypes.length; i++) { if (contentTypes[i].isKindOf(javaContentType)) { String[] ext = contentTypes[i].getFileSpecs(IContentType.FILE_EXTENSION_SPEC); extList.addAll(Arrays.asList(ext)); } } The list should be a set instead (to avoid duplicates). Also, the "for" should be inside the "if" that tests whether the Java content type is null (I would not bother taking that possibility into account though, since the manifest for jdt.core will always define it). Thanks Rafael. Released changes to Util#getJavaLikeExtensions() to use isKindOf(...) instead and use a HashSet to filter out duplicates. Thanks, the fix is working well for AJDT. Verified for 3.2 M5 by user |