Oxygen XML Forum

We have a Git-hosted Oxygen project used by about 50 writers.

When new Oxygen versions are released, we update our files to take advantage of bug fixes and new features. Examples include:

• Enabling new Oxygen features in the .xpr file
• Adjusting transformations and Schematron checks to reflect fixes in Oxygen's DITA-OT publishing engine
• Removing bug workarounds and using newly supported features in CSS files

Unfortunately, it is an ongoing challenge to keep writers on recent Oxygen versions. I send out email reminders for major releases and minor maintenance updates. I ask team managers to verbally remind writers when I roll out configuration changes that are particularly version-dependent.

And yet, I continue to find writers using old versions. Oxygen v25.0 is due out soon, and yesterday I helped a writer who was still using Oxygen v23.0. Over the last few months, I encountered several writers still using v24.0. This is concerning, as there can be correctness issues when an authoring/publishing environment assumes the presence of fixes that are not there.

Perhaps the .xpr file could declare the minimum version and build number needed for the authoring/publishing environment to be safely used:


Each time Oxygen loads the .xpr file (opening or switching between projects), if either the version or the build number is less than the specified value, the tool could issue a dialog box indicating that a newer version is needed for the project. This should not be a blocking requirement; the user might not be able to upgrade at that moment. But the check should be persistent enough to motivate an eventual upgrade.

If anyone else would find this feature useful, please reply and share your thoughts!

Hi Chris,

I registered an internal issue for this EXM-51298.
I think this functionality can be added to Oxygen by an add-on. This may contribute a preferences page (that can be stored to the project level) with those version options and present a notification every day or maybe more often when a number of editors are opened. What do you think?

Best regards,
Cosmin

Hi Cosmin,

Your proposed solution sounds good to me! Oxygen has a "required add-ons" setting in the .xpr file:


and the add-on settings would be stored in the .xpr file, so the machinery is already there for the add-on to install itself in a fresh Oxygen/Git environment.

I am open to any criteria for issuing the reminder:

• Every time the .xpr is loaded (opening an .xpr file, switching between .xpr files)
• Every calendar day
• Every N editing window openings

The specific method is not too important to me. The add-on could even allow multiple methods to be configured. I am happy with whatever is most convenient to implement.

Thanks Cosmin!

If you have a Java developer in your company I can guide you for creating this add-on. This is not a common use case and it's not high priority for us to implement.

Here are some useful links:

• https://www.oxygenxml.com/doc/versions/ ... lugin.html
• A sample add-on that can be used as a starting point: https://github.com/oxygenxml/sample-plu ... ace-access
• The current version and the build id can be obtained using the "getVersion()" and "getVersionBuildID()" methods from the "PluginWorkspace": https://www.oxygenxml.com/InstData/Edit ... space.html. See also the "showWarningMessage(String message);" method
• The plugin extension that can be used for adding a preferences page: https://www.oxygenxml.com/doc/versions/ ... lugin.html
• Information about deployment https://www.oxygenxml.com/doc/versions/ ... ddons.html
• After the add-on is created you can add the update site and the ID of the add-on in these options, which can be saved to project level: https://www.oxygenxml.com/doc/versions/ ... sions.html

Best regards,
Cosmin

Hi Cosmin,

Unfortunately we don't have a Java developer in our particular group. Maybe I can find some time next year to try to start learning it and make some progress on this. I appreciate all the links you provided, they will certainly be helpful!

- Chris

I might need to figure this out sometime soon. We recently had a case where a writer corrupted their map due to this bug, even though I had emailed the group with information about the maintenance release that fixed this bug.

Hi Chris,
You can start by cloning this sample: https://github.com/oxygenxml/sample-plu ... ace-access, import it as a Maven project in the Eclipse IDE and try to build it: https://dzone.com/articles/importing-a- ... -eclipse-1 (you should skip the "Download an Existing Maven Project" and "Creating a Run Configuration" parts)
After you can test this sample-plugin in Oxygen like this: https://www.oxygenxml.com/doc/versions/ ... n.redirect

Then you should modify this sample to implement the version checking:

1. Add the extension for the options page in the plugin.xml file
2. Add the class that extends OptionPagePluginExtension and creates the options panel.
3. Check the version and the build and show a warning in CustomWorkspaceAccessPluginExtension

I attached a zip that contains these changes: . You should copy the "src" folder and the "plugin.xml" over the ones from your sample plugin.

Note that the Java Archive file that can be used for deploying the add-on can be found in the "target" directory after invoking "Maven install".

Best regards,
Cosmin

Cosmin - this is fantastic, thank you!! As soon as I complete my current task, I will try this out.

Maybe this will be the kick in the pants I needed to finally start learning Java...