Eclipse Community Forums: TMF (Xtext) » org.eclipse.core.contenttype.contentTypes support

Help

Home

Home » Modeling » TMF (Xtext) » org.eclipse.core.contenttype.contentTypes support

Show: Today's Messages :: Show Polls :: Message Navigator

org.eclipse.core.contenttype.contentTypes support [message #1688295]

Fri, 20 March 2015 12:43

Ed Willink

Messages: 7098
Registered: July 2009

Senior Member

Hi

I've finally identified why my Xtext editors have an irritating log
message (Bug 453669) when saved, whereas the Xtext Xtext editor does not.

The difference appears to be that Xtext editors used to use the
org.eclipse.core.contenttype.contentTypes extension point but don't any
longer. My editors still do.

The problem seems to arise because an Xtext source may be either ASCII
text as seen in the editor, or an EMF model. Thus when
FileDocumentProvider.getCharsetForNewFile prepares for save, the
RootXMLContentHandlerImpl.contentDescription uses
URIConverter$ReadableInputStream.read which throws an NPE when
attempting to use the null encoding 'identified' in a non-XML file.

Failure to support org.eclipse.core.contenttype.contentTypes seems like
a retrograde step. Is this intentional, or should I raise a Bugzilla
suggesting that an XtextContentHandlerImpl override of
RootXMLContentHandlerImpl is needed to support the dual source file
representation that Xtext facilitates?

Regards

Ed Willink

Report message to a moderator

Re: org.eclipse.core.contenttype.contentTypes support [message #1688351 is a reply to message #1688295]

Fri, 20 March 2015 14:17

Ed Willink

Messages: 7098
Registered: July 2009

Senior Member

Hi

Correction: the problematic org.eclipse.core.contenttype.contentTypes
support only arises if the (manual) genmodel contains a non-blank
contentTypeIdentifier. i.e. a self-inflicted problem invoking an
unsupported combination of functionalities.

Regards

Ed Willink

On 20/03/2015 12:43, Ed Willink wrote:
> Hi
>
> I've finally identified why my Xtext editors have an irritating log
> message (Bug 453669) when saved, whereas the Xtext Xtext editor does not.
>
> The difference appears to be that Xtext editors used to use the
> org.eclipse.core.contenttype.contentTypes extension point but don't
> any longer. My editors still do.
>
> The problem seems to arise because an Xtext source may be either ASCII
> text as seen in the editor, or an EMF model. Thus when
> FileDocumentProvider.getCharsetForNewFile prepares for save, the
> RootXMLContentHandlerImpl.contentDescription uses
> URIConverter$ReadableInputStream.read which throws an NPE when
> attempting to use the null encoding 'identified' in a non-XML file.
>
> Failure to support org.eclipse.core.contenttype.contentTypes seems
> like a retrograde step. Is this intentional, or should I raise a
> Bugzilla suggesting that an XtextContentHandlerImpl override of
> RootXMLContentHandlerImpl is needed to support the dual source file
> representation that Xtext facilitates?
>
> Regards
>
> Ed Willink

Report message to a moderator

Previous Topic:	CrossReferences [..\|STRING] and AutoEditing is not nice
Next Topic:	Serialization issues

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Mon Apr 19 10:32:16 GMT 2021

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter