Community
Participate
Working Groups
For AJDT/AspectJ we'd like to make use of JDT's ability to handle compilation units based on non-.java extensions, added in 3.2M4. Currently we'd have to register .aj files as containing Java source, but this doesn't feel right, as .aj files are intended to contain AspectJ code (leaving .java files to contain only pure Java code). Also doing so would cause the Java editor to be used for .aj files, instead of our own AspectJ editor. I therefore think it makes more sense to define a new contentType for AspectJ source, as an extension of the Java source contentType (as the AspectJ language is a superset of Java), e.g.: <content-type id="ajSource" name="AspectJ Source File" base-type="org.eclipse.jdt.core.javaSource" file-extensions="aj"/> But Util#getJavaLikeExtensions only looks at the file extensions associated with the Java source contentType. It would be a fairly straightforward change for it to also look at file extensions associated with contentTypes which have Java source as their base type.
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
