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: 7655
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 Go to previous message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
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:
  

[ Syndicate this forum (XML) ] [ RSS ]

Current Time: Thu Apr 25 14:18:59 GMT 2024

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

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

Back to the top

Sign up to our Newsletter

A fresh new issue delivered monthly