Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » TMF (Xtext) » org.eclipse.core.contenttype.contentTypes support
org.eclipse.core.contenttype.contentTypes support [message #1688295] Fri, 20 March 2015 12:43 Go to next message
Ed Willink is currently offline Ed WillinkFriend
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
Re: org.eclipse.core.contenttype.contentTypes support [message #1688351 is a reply to message #1688295] Fri, 20 March 2015 14:17 Go to previous message
Ed Willink is currently offline Ed WillinkFriend
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
Previous Topic:CrossReferences [..|STRING] and AutoEditing is not nice
Next Topic:Serialization issues
Goto Forum:
  


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

Powered by FUDForum. Page generated in 0.02152 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top