Problems with frameworks in Oxygen 14

[stdu]

I have a strange problem with Oxygen XML 14.

I have installed the new Oxygen XML 14 - parallel to Oxygen XML 13.2. After the installing I've changed in Oxygen 14 the framework directory from the V13.2-directory to the V14-directory. After this I tried to install a framework from our server with the new add-on-function. This process functioned well, but after the restart of Oxygen XML 14 he hasn't installed the framework from server and the Add-on-Manager sais while starting:

The following errors were encountered while installing add-ons:
Installation of Testframework failed. Reason: Das System kann den angegebenen Pfad nicht finden

When I open now a standard framework, like TEI P5, the actions displays in section "Author" under the column "name" only "${i18n(item)}" and when I try to change an operation in a framework action, Oxygen shows me the following message:

Code: Select all

C:\Programme\Oxygen XML Editor 14\${framework}\tei.jar - C:\Programme\Oxygen XML Editor 14\${framework}\tei.jar (Das System kann den angegebenen Pfad nicht finden)

Under "options > global" oxygen says, that the actual framework directory is

file:/C:/Programme/Oxygen%20XML%20Editor%2014/frameworks

Deinstalling and reinstalling Oxygen 14 has brought no result, the error remains. Has anybody any idea, what's going wrong?

[adrian]

Hello,

Uninstalling and reinstalling won't make a difference, the settings and addons are located elsewhere. Depending on the platform the settings folder is located as follows:
- Windows XP - [user-home-folder]\Application Data\com.oxygenxml
- Windows Vista/7 - [user-home-folder]\AppData\Roaming\com.oxygenxml
- Mac OS X - [user-home-folder]/Library/Preferences/com.oxygenxml
- Linux - [user-home-folder]/.com.oxygenxml
In Windows if you have trouble locating the AppData/Application Data folder(it is hidden), open Windows Explorer and in the Address bar type: %APPDATA% and press Enter.

If you want to clear all addons, remove the folder named extensions from the settings folder.

My guess is there's a mistake somewhere in the configuration of the addon that you've installed from the addon update site.

Regards,
Adrian

[stdu]

Hello Adrian,

thanks for your reply. I have removed the whole folder com.oxygenxml (after backup, of course) and the oxygen 14 installation. After this, I've reinstalled and started oxygen, inserted the licence and looked directly in the documenttypes "TEI P5" and "DocBook 5": the error (described above) exist already here - before installing any add-on.

PS: I have Windows XP SP3 and Java 1.7.0_03-b05

[adrian]

Hi,

The problem with the path mentioned in the error is that the ${framework} editor variable (macro) should have been expanded to:
C:\Programme\Oxygen XML Editor 14\frameworks\tei
Instead it seems to be taken ad literam, as a path and made relative to the Oxygen installation directory: C:\Programme\Oxygen XML Editor 14\${framework}\tei.jar. Obviously, this won't work.

What doesn't make sense is that there should be no problem with the configuration since you started from scratch. Did you import old options or did you use a custom frameworks directory after this clean installation?

I've sent you a private email (subject: Problems with frameworks in Oxygen 14) with instructions for enabling logging/debugging in Oxygen.

Regards,
Adrian

[stdu]

Hi Adrian,

no, after the install from scratch (which means deleting com.oxxgen and reinstalling oxygen 14), I only have openend the already existing document types TEI P5, DITA and DocBook and tried to change an java-class in an operation.

I still have a parallel oxygen 13 installation, but these installation should not affect the oxygen 14 installation, since I have deleted the whole settings folder?!

Regards,
Stefan

[adrian]

Hi,

We've tested this internally but the only way we were able to reproduce the issue was to use the frameworks from v14.0 in v13.2, then duplicate a framework there in v13.2 then run v14 which then imports that framework and it is unusable. This scenario is somewhat convoluted so I don't think that's what happened on your side.

I've also looked at the log you've sent us but there's nothing obvious that could explain this.

The separate installations do not interfere with each other (assuming they are in separate folders)), but if you started v13 before starting v14, then v14 will import the options from v13 when first started, though this options import should not present issues.

Could you please try a few things in v14 and let me know if they change anything:
- Go to Options > Preferences, Document Type Association and press Restore Defaults. This should resolve the problem if somehow a broken framework/document type is there. If this doesn't make any difference, go to next step.
- Options > Reset Global Options - This will reset all options to Oxygen's defaults. If this doesn't make any difference, go to next step.
- Install Oxygen v14 again in a different folder, make sure you install it in a clean folder.

Also, I've seen in the log that you started Oxygen XML Author from the Oxygen XML Editor installation. Can you please confirm if the same issue appears when starting Oxygen XML Editor.

Regards,
Adrian

[stdu]

Hi Adrian,

in Oxygen XML Editor 14 the error appears as in the Author version. The installations are of course in two different directories. I also tried all your suggestions step by step - nothing changed. At the end I have deleted all oxygen (v13.2, too) folders and files, which I could find on the pc and made a fresh v14 install to an new folder named "xyz". Unfortunately the error remains.

Perhaps I can test the installing of v14 on our laptop tomorrow.

Regards,
Stefan

[adrian]

Hi,

I've sent you a private email but I'm also including the explanation here in case anyone else encounters this.

We have reproduced the problem. What happens is that when you duplicate a default document type (framework), the duplicate still contains references to ${framework} (an editor variable introduced in v14.0 that expands to the location of the current framework). The problem is that the duplicate framework is by default an internal framework (stored in the options) and does not have an established current framework directory (like an external framework has).

We are already working on a fix for this problem and it will be available in the next maintenance build of Oxygen v14.0 (in a few days). We'll post a notification on this thread as soon as it becomes available.

Meanwhile, a simple workaround for the problem is to press OK immediately after duplicating the default document type (framework), then press Edit and you will see that ${framework} has been replaced with ${frameworks}/framework_dir and you will now be able to add actions and choose operations.

Regards,
Adrian

PS: Regarding the action names in v14.0, it's normal for them to be of the form ${i18n(action_id)} because they are now localized in several languages. These editor variables (i18n) will be expanded to the corresponding translations for each action id.
The localizations are usually stored in a file named translation.xml from the directory: <frameworks>/framework_name/i18n (${framework}/i18n/ mentioned in the Classpath section).

[stdu]

Hi Adrian,

I read only now your post and now I'm a bit confused. If I understood you correctly, the problem appears only when you duplicate an existing default framework (like TEI P5) - and only in the duplicated framework.

But I've made a fresh install (without any imports from older versions) and openend (wihtout duplicating) in Oxygen 14 Editor a default document type association (for example TEI P5). In this default framework I opened in the tab "author" an action and tried to change the java-operation (button "choose" under "invoke the operation") - and then the error message appears.

I've tested this with an installation from scratch on our laptop (where no Oxygen was installed before) and I could reproduce the bug (Laptop OS is Win XP SP3 with Java 1.6.0_33). Curiously, the editorvariable {$framework} functions well in the tab "Classpath" - the expanded path here is displayed correctly.

In conclusion, I'm not sure, if you have reproduced the same bug?

Regards,
Stefan

[adrian]

Hi Stefan,

I have checked and you are correct. The problem happens in both situations (edit or duplicate a default document type), it's the same bug. However, we should have the new maintenance build ready and available (with the bugfix) by tomorrow. Apologies for any inconvenience this may have caused.

There is a workaround for editing the default document type as well, but I'd recommend waiting for the new build rather then altering the document type just to make this work. The workaround is to replace in all the Classpath URLs the ${framework} editor variable with ${frameworks}/framework_dir. In your case framework_dir is tei.

Regards,
Adrian

[adrian]

Hello,

I just wanted to let you know that this problem has been resolved in the latest maintenance build of Oxygen 14.0, 2012070512 (released July 6th):

Options GUI: When editing/duplicating a document type, the ${framework} editor variable from URLs in the Classpath was not expanded when choosing an operation for an Author action.

You can download it from our web site:
http://www.oxygenxml.com/download.html

The list of bug-fixes can be found here:
http://www.oxygenxml.com/build_history.html#2012070512

You can install the new build in the same folder as the previous installation, it will automatically upgrade it.
Before you upgrade, if you have added files or made changes to any of the files from the Oxygen installation folder (especially the frameworks folder), you may want to create a backup of them because they will be overwritten during the upgrade procedure. Custom frameworks will be preserved but we recommend backing them up anyway, just to be safe.

Let us know if you encounter further problems with this new build.

Regards,
Adrian

[stdu]

Hello Adrian,

meanwhile I could install our framework via the new add-on feature. But I still have two minor problems/questions:

1) Our custom frameworks not appears per default in "Preferences > Document Type Association". I first have to activate "Use custom frameworks (Document Type Associations) directory" in "Preferences > Global" and set the directory explicitly to

Code: Select all

C:\Dokumente und Einstellungen\userxy\Anwendungsdaten\com.oxygenxml\extensions\v14.0\framworks

I don't think, that is intended. What I have overlooked?

2) Exists a editor variable to the path of the add-on framework directory (i.e. to \\com.oxygenxml\extensions\v14.0\framworks)?

Thx & Greets,
Stefan

PS: Oxygen XML Author 14.0, Build id: 2012080717

[alex_jitianu]

Hello Stefan,

1) Please check if the add-on archive contains the root directory of the framework. The behavior you describe can happen if instead of archiving the framework's root directory you've archived the containing files.

If the archive has the correct structure you don't have to set anything in "Use custom frameworks".

2) The ${framework} variable expands to the directory of the framework and the ${frameworks} variable expands to the frameworks directory in which the add-on is installed.

As a side note, the frameworks directory for your add-on is actually :

Code: Select all

...\com.oxygenxml\extensions\v14.0\frameworks\{update_site_dir}

, but because the framework is not packed correctly the framework is discovered only when you manually set the custom framework directory to

Code: Select all

...\com.oxygenxml\extensions\v14.0\frameworks

Best regards,
Alex

[stdu]

Hi Alex,

1) thx for the hint, it functions now! In fact I archived the containing files and not the directory.

2) I would like to use an editorvariable for \com.oxygenxml\extensions\v14.0\frameworks\update_site_dir\frameworkxyz\ in Preferences > Perspective Layout > Fixed Layout. But all editor variables, I've used there (${framework}, ${frameworksDir} and ${frameworks}) always point to the frameworks directory in C:\Programme\Oxygen XML Editor 14\frameworks. It isn't very important, but if there were a proper editor variable, this would be very nice...

Thx & regards,
Stefan

[alex_jitianu]

Hi Stefan,

2) You are right, all these $framework variables, when used outside of a document type will expand to the defaults. But I understand the need to refer from outside of a document type a certain framework location. I will add an improvement request to provide a new variable like ${framework(xyz)} that will give the location of the framework with name 'xyz'.

Meanwhile you might find useful the default options support:
http://www.oxygenxml.com/doc/ug-editor/ ... tions.html
You could export an options file in which the layout file points to ${oxygenInstallDir}/preferences/{my_custom_options}.xml, then instruct the user to copy both {my_custom_options}.xml and {my_custom_layout}.layout inside ${oxygenInstallDir}/preferences and Oxygen will automatically load the layout file.

Best regards,
Alex

[stdu]

Hi Alex,

thx for the feature request and the hint!

At last I've unfortunately still another question: I've checked "Enable automatic updates checking" in Preferences > Add-ons. Oxygen recongnize the update (in "Manage add-ons"), but the program doesn't show any message ("update available" or similar) when the user starts the program. Is this intended?

Greets,
Stefan

[alex_jitianu]

Hi Stefan,

We want to avoid checking for updates to often so we'll check once in four application launches. So the user will get notified, but not always as soon as the update is uploaded. The user can always use "Help->Check for add-ons updates..." to manually check for any updates.

Do you believe we should check more often or perhaps we should add a configurable update policy, like: check daily, check on each start-up, etc ?

Best regards,
Alex

[stdu]

Hi Alex,

thanks for your reply - I didn't know, that Oxygen checks only each fourth application launch for updates. That's okay, but an update policy would be useful: when I launch a new version of a framework, I inform normaly all users per mail and perhaps it is better, when the users get the next Oxygen start a corresponding message.

Best regards,
Stefan