Reload settings file

[dcramer]

Hi there,
This is related to http://www.oxygenxml.com/forum/topic5235.html and has three parts:

First, I have an build.xml and xslt that massages the .com.oxygenxml/oxyAuthorOptionsSa12.1.xml file to change certain configuration options that I want to manage centrally. For example, I might configure some new External Tools and distribute them to the writers. Is there a way to cause Oxygen to reload the settings file without quitting and restarting Oxygen?

Second, so far I've been making these changes in the global settings file. I notice that if you configure a project-level External Tool, it copies the global External Tool definitions from the .com.oxygenxml/oxyAuthorOptionsSa12.1.xml file into the .xpr file. Does that mean if I later have them pull down updates to the .com.oxygenxml/oxyAuthorOptionsSa12.1.xml, that those updates will not be available in projects for which they have already defined project-level External Tools?

Finally, is there a schema available for the .com.oxygenxml/oxyAuthorOptionsSa12.1.xml or .xpr formats?

Thanks,
David

[adrian]

Hello,

Oxygen only loads the global options file(oxyAuthorOptionsSa12.1.xml) at startup.
However, you can manually import the options file during an Oxygen session: Options -> Import Global Options.

Project level options(from the .xpr) override the global options(oxyAuthorOptionsSa12.1.xml). This means that the sections of options(option panes) that are kept in the project will override the global options from the said sections.
So if a user has project options(in the .xpr) for some sections, any modifications you make to the global options in those sections will not be reflected in the options in use by the user.

So, for your External Tools example you are correct, the updates made to the global options file will not be available for users that have defined project-level External Tools in their project.

I'm afraid there isn't a schema available for either of the formats(options file or XPR). They just weren't meant to be manually edited.

But why are you using the global options file instead of the project options when you want to change an option for everybody?

Regards,
Adrian

[dcramer]

Hi Adrian,
Thanks for that information. I can see how things are intended to work and can probably adapt my system to it since this use of the External Tools feature is not long-term.

I serve as the tools developer for our group. Most of the writers don't want or need to think much about how Oxygen is configured. They just want to click buttons and have things happen. So I want to control centrally certain aspects of the Oxygen configuration. I can distribute a settings xml file at install time, but I also need to update their configurations, so I'll distribute a utility that they run which 1) transforms the settings xml file with an xslt to give them new External Tools and 2) updates their framework for our schema (a modified version of DocBook 5). So I'm not hand editing the xml file but transforming it and would use a schema to validate the result of my transformation.

In the long run, I'll create a plugin that adds a new menu of items that launch various actions (such as invoking ant with a certain target and parameters in the document directory) and I think that would make this problem go away. For now, however, we're using External Tools for most of that.

I'm using External Tools rather than validation scenarios because the logic for our builds is in an ant file and wouldn't lend itself to being reimplemented in a validation scenario.

Thanks,
David