How to prevent DITA-OT copy to user directory?

[jperkins]

The subject might not actually be the answer I'm looking for…let me explain the problem.

We have XMetaL installed on about 50 user workstations, currently running XMEE5.1. Every month we push out updates, bundled as MSI packages and using standard Microsoft tools.

Now we are looking at updating to XM5.5. In this version, when you try to generate output for the first time it will copy the entire DITA_OT directory to the current user's Application Data directory. The transform then proceeds and everything is good.

However, after the initial copy, changes made to that source DITA_OT directory are not detected, and are never copied to the user's Application Data directory. Consequently, our updates are never making it into the copy of the DITA-OT that XMetaL uses.

MSIs are not allowed to write the user's data area, so we've got two options, as I see it:

1) On XMetaL startup, recopy the DITA_OT to the user's data area. This is a lot of files, and even checking for changes first can take some time. XMetaL already takes a long time to start, so I'd rather avoid this if I can.

2) Convince XMetaL to use a DITA_OT that lives somewhere else on the system, and not copy it. This is the solution I would prefer, if it could be managed.

I tried setting DITA_OT_DIR, but that just triggers a copy. Is there any way to tell XM5.5 where to find the OT?

I can see how this might be confusing – I can provide additional clarification if needed.

Thanks!

Reply

[Derek Read]

You can do this by changing the following file:
AuthorDITAXACssharedrenditionsdita_print.txt

That file should contain the following setting:
dita_ot_per_user_version = 1

Changing the value to any higher value than the current one will cause the DITA OT to be redeployed the next time output is generated.

So, because you are deploying new files already you should be able to include an updated copy of this file in your manifest. To remove the need to keep track of the last value I would suggest using the date in the form yyyymmdd (or if you plan to do more than one deployment per day you might include the time as well: yyyymmddHHmm). Note that this value is treated simply as an integer to compare with the previous integer and is not an actual date, so pick your format beforehand and stick to it. You could also simply use 1, 2, 3, if you don't mind keeping track of that.

I'm attaching a screenshot of what the user will see if you change the value to 20090121.

Background:
Making XMetaL Author Enterprise compatible with Vista forced us to make some changes. In 5.1 and earlier we deployed and ran the DITA OT inside Program Files. On Vista by default (and for Limited Users on XP) this folder is locked down tightly. Once a product has been installed it should not write anything to this folder and the DITA OT writes inside its own sub folders. So, we still install to Program Files, but the first time you generate output a copy of the DITA OT is deployed to the current Windows user's per-user folder (which can be in various locations depending on your version of Windows and how your IT people have set things up). This also means that IT staff (network admins) can deploy XMetaL Author Enterprise once on a machine (for all users) while different users that log into that same physical computer will each have their own separate copy of the DITA OT automatically deployed.

Reply

[jperkins]

Thank you, Derek. That was a very helpful response. I'd like to ask a follow-up, if I could:

We don't use XMetaL's OT. Instead, we maintain our own version, which gets installed to a different location entirely (we do this because we actually have a suite of tools, and we want them all to use the same OT). For XM5.1, this was as simple as setting a handful of environment variables (DITA_DIR, DITA_OT_DIR, etc.) to the new location.

Is there anything like this for XM5.5? That is, is there something I can set to make it look at C:DITA-OT instead of C:D and SCurrentUserApplication DataSoftQuad…DITA_OT?

If that is possible, then I can set print_local.xml just once and forget about it, and carry on like we did with XM5.1 (which was working very well for us).

Updates:

I tried modifying dita_ot_per_user_location in dita_print.txt but it does not seem to have any effect.

Looking at what is being written to Local Settings/Temp/XMetaL during the transformation, I see that DITA_OT_DIR=C:DITA-OT (correct, for me) in dita.bat, but it gets overwritten in xm_dita_envar.bat.

Reply

[Derek Read]

The DITA_OT_DIR parameter should work in 5.5 but usage of this parameter (in any release) and whether or not it will actually successfully end in output being generated with a given copy of the DITA OT depends very highly on which version of the DITA OT is being used and the changes that have been made to it. In some cases making changes to the DITA OT might also require making changes to the files located in AuthorDITAXACssharedrenditions and making such changes is not documented nor supported, which means that I would suggest if anything is done to them that they only be done by our own Professional Services team (who would then be on the hook for supporting those changes according to any contracts signed).

The only thing we test this parameter against is a completely “standard” copy of the DITA OT located in a different folder on the same machine, meaning that if you take what we install in C:Program FilesCommon FilesXMetaL Shared and duplicate it exactly in a different location that parameter should work. Beyond that if there are issues then unfortunately that is far to complex to support (hopefully the complexities involved with testing this stuff is understandable).

I will see if I can find out if the combination of using DITA_OT_DIR with making modifications to the setting dita_ot_per_user_version has even been thought about.

That might take a while as I suspect nobody has tried this (certainly our QA people have not) and so I would probably need to run some tests myself.

Reply

[jperkins]

Certainly, I understand. If our transforms fail to run that is all on us to fix. However, this approach has been working successfully for us since XM5.0. And run successfully under 5.5 too, but only after it copies our custom OT to Application Data first.

I only mentioned DITA_OT_DIR because it is the approach we have used in the past. If I can set dita_ot_per_user_version to C:DITA-OT and have it stick that would be fine with me, too. Whatever works! But right now it seems that no matter what value I give dita_ot_per_user_version, it ends up pointing back to the user's Application Data directory in xm_dita_envar.bat when a tranform is fired.

I appreciate you looking into this, Derek. Many thanks!

Reply

[jperkins]

Sorry to resurrect such an old thread, but we finally addressed this problem and I wanted to post the solution in case it might help someone else.

If you want to use your own version of the DITA-OT, and don't want it copied into the Application Data folder, you need to comment out line 2466 of DITAXACssharedDitaRenditions.js:

[code]dita_ot_dir = this.CheckForDitaUpdate(dita_ot_dir);[/code]

We had been letting XMetaL copy our toolkit, and just updating the version number in dita_print.txt, as Derek suggested above. But it recently stopped working, and would prompt to copy the OT on every transform. Since we are still in active development and change our DITA-OT plugins frequently, we decided to bite the bullet, modify core, and shut the feature off.

Reply

[Su-Laine Yeo]

The following solution has also been pointed out to me:

1) Start XMetaL.
2) Click Tools > Configure Output.
3) In the Configure Output Options dialog, click the Advanced tab.
4) In the “Other output parameters” box, add the following line: cmd_dita_ot_per_user_version  =  disable
5) Click OK. This will add a setting to the print.local.xml file in your C:Documents and SettingsApplication DataSoftQuadXMetaL6.0 folder.

Reply

[Su-Laine Yeo]

This procedure might also be helpful: [url=http://forums.xmetal.com/index.php/topic,997.msg3119.html#new]Using a copy of the DITA Open Toolkit on a shared drive[/url].

Reply

[Author]

Posts