Community
Participate
Working Groups
While trying to create my own documentCreation extension for "XML" in general, it seems the one provided by the ant.ui plugin "wins", at least for non-existent files, when the document is created before a resource exists. Is this intended? It seems the definition of the ant documentCreation and documntSetup, being associated with the "xml" and "ent" file extensions are claiming responsibility for being appropriate for all xml and ent files which seems inappropriate. (I know less about the macrodef file extension). I believe, once other fixes are in place for bugs I've recently opened, that the ant document creation and setup could be defined entirely in terms of contentTypeId, thereby requiring a "positive hit" on a true ant file instead of xml and ent files in general (not sure how the ent file is identified as "for ant documents".) related to https://bugs.eclipse.org/bugs/show_bug.cgi?id=64684
I would have thought that specifying the extensions and the contentTypeId would mean that only files that have the correct extension and contentTypeId would be deemed appropriate?
It may be more complicated than my original writeup. From looking at the code in getDocumentFactory, it appears if there's any match for content types, then only that list of content types is used (and extensions are not used). But, if mulitple matching contentTypes, then the first one is "blindly" taken as the correct one. To see this as a problem may depend on the fix I've suggested in https://bugs.eclipse.org/bugs/show_bug.cgi?id=64692. If this is the case, perhaps the ant content type definition could be improved to only apply to certain cases (file names) if there are no contents. That code in getDocumentFactory, though, shows that if there happened to be no content types found for an "xml", "ent", or "macrodef" file extension, then the ant document creation would be used ... which is why I say its "over defined". For setup participants, its even more complicated, since there (in getDocumentSetupParticipants), matches on content types and extensions are deliberately combined, all to be "participants". The "over definition" in this case is part of what gives rise to the bug I opened as https://bugs.eclipse.org/bugs/show_bug.cgi?id=64684 I say only "part of", though, since even if the ant definition was more restrictive, in general there still seems opportunity for easy conflicts, and I'm not sure its clear what liberties "particiapant" can take.
It would appear to me that this is more a bug in the platform text support than the Ant use of the extensions. If nothing changes in the platform text support we could scale back to not be associated with the xml extension.
I'll have a look in conjunction with the other ones David filed.
Rafael, hope you don't mind me adding you for comment on the follow "principle". If you agree, I think it should be part of the documentation (for faq?) for how to implement extensions to honor contentType. [Guess there's no way to enforce it, but would be nice to document intent, I believe;] The more I think about these issues, the more I think there should be a few simple rules that everyone follows (in base and in add-ons), or it will be very confusing, and hard to maintain and migrate. The first one is obvious, the seond maybe not. And the third one shold be obvious too, but may require a tiny bit more work. 1. For extensions which provides filetype or filename for association (alone), then those relationships should continue to be honored as they were. This is both for backwards compatibility and for those cases where there is no contentType defined for certain files (though would be easy to do so). 2. For extensions which honor contentType for associations, then that is *all* they should honor. They should ignore file extensions and filenames if specified. There's two reasons for this: A. the content type describer can take file specs into account however they want, so at best its redundant. B. If not done this way, there will eventually end up a "hodge podge" of differenct rules and contracts for how contentType and filespecs interact. Some implementors might want to use some "filtering" mechanism, some might want to include with "and" relation, some an "or" relation. It will be very unpredicable to us end programmers -- and all neededlessly complex, since the content type is powerful enough to handle how filepecs can best be handled for that contentType. I can not think of a scenerio where it would be required or even helpful to have both contentType and file specs (and, if it seems like it was to anyone, then my gusss that the content type was not fully defined). Oh, and third principle: if a content type is used, then the assocation provider much "lookup" the hierarchy if they don't find one at a lower level. That is if there is not an association for "XSD", then they would look for "XML" and if not one, would look under "TEXT".
David, although you say "extensions", it seems you are talking about extension points, since only extension point providers are in charge of interpreting configuration elements. Please correct me if I am wrong. Ideally, we would have the whole SDK relying on content types for file association. Since this support came too late, and there is also a need to support ad-hoc file association for backward compatibility, a mixed support is necessary for *extension points* that allowed file associations in the past (we cannot just start ignoring the old attributes, that would be an API breaking change). So, some sort of extra work must be done by providers of extension points that supported file associations in an ad-hoc way and now also support content-type-based associations. I believe priority should be given to content-type-based associations (traversing the type hierarchy up to the root, if needed), and only if necessary, ad-hoc file name/extension associations should be taken into account.
Rafael, yes, I think we're saying the same thing. I did mean the extension point "provider", and I fully support backward compatibility, and I think your closing statement captures what I meant "priority should be given to content-type-based associations (traversing the type hierarchy up to the root, if needed), and only if necessary, ad-hoc file name/extension associations should be taken into account." I'd just add I'm not sure when it would ever be necessary to do both content type association and file name/extension associations. That is, if the content type was specified in an extension, then there'd be no reason to also specify filename/extension. At least, no reason I know of (and would seem to be confusing to allow both). I'm just picking on this ant case since its an early adopter :) but it provides a case in point. Consider the following extensions in org.eclipse.ant.ui plugin.xml. For documentCreation, if a resource has a contentType, then the file extensions specified are ignored. For documentSetup that's not true, even if the resource "fails" the antContentTypeId test, then its included anyway if it meets the "xml extension" test. This is why I say its "over defined". So, "ant based" partitioning is available for every xml file!? (I haven't tested since M9, but that's the way it was working). <extension id="org.eclipse.ant.ui.AntDocumentFactory" name="%antDocumentFactory.name" point="org.eclipse.core.filebuffers.documentCreation"> <factory extensions="xml, ent, macrodef" contentTypeId="org.eclipse.ant.core.antBuildFile" class="org.eclipse.ant.internal.ui.editor.text.AntDocumentFactory"> </factory> </extension> <extension id="org.eclipse.ant.ui.AntDocumentSetupParticipant" name="%antDocumentSetupParticipant.name" point="org.eclipse.core.filebuffers.documentSetup"> <participant extensions="xml, ent, macrodef" contentTypeId="org.eclipse.ant.core.antBuildFile" class="org.eclipse.ant.internal.ui.editor.text.AntDocumentSetupParticipant"> </participant> </extension>
Ok, I got it, when an extension (supposedly) wrongly uses both types of associations, the extension point provider should interpret only the content type-based one. This makes sense to me. For a given configuration element, either old or new style associations should be used, but not both.
I am looking for direction on what remains to occur for the Ant component.
Looking for direction from Kai on this one - i.e. does Ant need to do anything for this in RC3?
We are getting done to the crunch here. Is the current recommendation to remove the file extensions and just use the content type id?
I am going to move Ant to only use the content type. Currently two Ant document setup participants are created: one based on the content type and one based on the file extension. I would agree with comment #8 that the extension point should only take one or the other as I do not believe most extension definers would expect this behavior.
Changes released to org.eclipse.ant.ui plugin.xml to remove the association with the xml and ent extension for both the document factory and document setup. I have left macrodef as I doubt others are interested in this extension. This will result in problems for some users who really want all xml and ent files to be associated with documentCreation and setup for ant.ui even though the content of the file cannot be identified as ant buildfile content. Case in point is for ent files that define Ant targets but do not fully specify the required Ant buildfile structure that is mapped to the Ant content type (top level project element). This ent files are xml "entity" included in the "main" Ant buildfile. Any ideas for a better solution are appreciated.
I am going to roll this back. Case in point: create a new file called build.xml Ctrl-space to add the buildfile template No syntax highlighting as the file did not originally have the top level project element specifying Ant buildfile content. You have to close and reopen the file to get the content type recognized.
Good (counter) use case. I know in some of our editors, we have to jump through hopes to accomidate changes to content type -- bascially un-configuring and re- configuring the editor. I'll try to polish up the solution we have there, to see if can be made generally applicable to editor framework.
re: comment 14 - I believe bug 90218 would address this part of the problem (for files named build.xml).
Changes released to org.eclipse.ant.ui plugin.xml to remove the association with the xml and ent extension for both the document factory and document setup. I have left macrodef as I doubt others are interested in this extension.
Please verify DarinW.
Verified.
