Description of problem: Editing of switchyard.xml by visual editor removes comments. Version-Release number of selected component (if applicable): 1.1.0.v20130912-2244-H393-M2 How reproducible: Steps to Reproduce: 1. Create a comment in switchyard.xml and save. 2. Modify something by visual editor. Actual results: The comment is removed. Expected results: The comment is present. Additional info:
Brian, Can you investigate this? I'm not sure if it is possible for us to support this using EMF. For the time being, I'd look at two possibilities: 1. See if there is an option that can be set on the resource/resource factory that will allow unsupported elements, including comments to be round tripped. 2. As a possible workaround, see if a "documentation" element is more feasible (you'll have to look at the schemas). Thanks, Rob
Yup. Will take a look. On a cursory search, it looks like there is an option we can use in the XMLResource (OPTION_USE_LEXICAL_HANDLER) that may help preserve comments (http://download.eclipse.org/modeling/emf/emf/javadoc/2.7.0/org/eclipse/emf/ecore/xmi/XMLResource.html).
Unfortunately we already seem to be using that in all our generated EMF resource factories, so that's not the issue.
Ok... I found a possible fix, but it's not pretty. Based on this forum post from 2008 (http://www.eclipsezone.com/eclipse/forums/t115996.html) I added 'mixed="true"' (http://www.w3schools.com/schema/schema_complex_mixed.asp) to the switchyard-v1.xsd schema, rebuilt an ecore, and merged the change with the existing config.switchyard.ecore model. Doing that, I was able to put a comment inside the <switchyard> element via a text editor, go in via the multi-page SY editor and change the model, save it, and have it persist. It completely hoses the nice clean structure of the XML when you do this, leading to some really messy XML formatting in the file. But it does work. Unfortunately this would require regenerating every single model across the board to add the "mixed" attribute to all the complex types we want to allow comments in, otherwise they get stripped out.
That said, modifying the schema is a bad idea. We may be able to do this in the ecore itself, but that may also have bad ripples. As a workaround, <sca:documentation> elements can be placed in various parts of the switchyard.xml file without causing too much trouble. We could look into adding a way in the editor to view/modify these documentation elements on a variety of places where supported (any element that extends CommonExtensionBase). And we may want to have the SwitchYard root element extend CommonExtensionBase as well to get documentation at the base level of the config. This is very much an enhancement at this point obviously. And it's definitely a bug that we don't preserve xml comments.
Agree with Brian's assessment here. Including comments introduces risk and negative impact from a usability standpoint (formatting) with questionable value to end users. There are <sca:documentation> elements available, but it would make even more sense for users to record notes in the design-time repository which is also packaged with FSW. This should definitely stick around as a functional gap / enhancement though.