It's all about the answers!

Ask a question

[closed] DOORS and RPE Javascript version out-of-date. How to update to current version? Plus other tools.

Michael Sweger (113) | asked Apr 17 '23, 10:14 a.m.
closed Apr 20 '23, 3:26 a.m. by Ralph Schoon (63.2k33646)
I have DOORS v9.7.0.1 and RPE v6.0.6.  They are running Javascript 2015 that came with these tools.

However, I'd like to use the language features of a newer version of Javascript 2021 and later.

Can the Javascript be udated to a newer version separately from the update cycle of IBM's products and that it will work without problem assuming no javascript to backtool issues? Or, do I have to treat them as libraries extensions to the language and tell my RPE template to use the library. If so what about variations of javascript that is used?

What about doing the same for the Java language version for these tools or any of the DNG toolsets i.e. RQM etc? Or, do I have to have my code or the toolset pull in a different java language and treat it as a library?

Since I'm not the admin nor control when IBM tools are updated, the work around for me to use newer javascript and java language is via the library. Moreover, also wondering if my RPE template can use some python libraries via the RPE toolset library feature.

If an old version of DOORS only understands old javascript, one could pull data from DOORS using the old javascript, but manipulate it via user code and the newer javascript via RPE libraries before export to word etc.

Fariz Saracevic commented Apr 18 '23, 5:17 a.m.

For Publishing (formerly RPE), you can not update JavaScript version as it is embedded with Publishing itself. I would expect the same for DOORS. 

There are some options in Eclipse to update JavaScripting but I do not believe this would provide what you are looking for.

David Honey commented Apr 18 '23, 6:20 a.m. | edited Apr 19 '23, 12:53 p.m.

Use the JRE that is shipped in /server/jre for your ELM version. The use of later versions of Java is likely to be untested and unsupported, and you do so at your own risk.

Michael Sweger commented Apr 18 '23, 8:19 a.m. | edited Apr 18 '23, 8:35 a.m.
ok. since I'm not the admin of these tools, I will not be able to experiment to see what happens.....

Another case, is where one has developed RPE templates over time and each to an older version which may be based on older javascript versions. Thus, instead of updating all the templates to the latest javascript version the latest tool is using, one could just have the RPE template with the older javascript point to the compatible javascript library version. Where it gets tricky, is if one has a template that includes different templates to create a document and with each based on a different version of javascript. Thus, the namespaces for each javascript will need to share data globally amongst the templates.  I.e. template 1 is the TOC, template  2 could be the main text body, and template 3, could be appendixes with each of these getting its data from other ELM toolsets such as RQM and each using a different version of javascript.   This would be an interesting case of backwards compatibility since some orgs may have alot of templates that they don't want to go back and have to maintain to bring them up to date since they already work.

The question has been closed for the following reason: "The question is answered, right answer was accepted" by rschoon Apr 20 '23, 3:26 a.m.

One answer

permanent link
Ralph Schoon (63.2k33646) | answered Apr 20 '23, 3:26 a.m.

 I would like this answer to be answered somehow. The answers seem to be

  1. RPE - You can not change the JavaScript version as it is packaged with the product. If anyone knows, it is Fariz. If you have older reports that need to be run in newer versions of RPE, you might have to update the report in case there are breaking changes in the new JavaScript. I do not know how likely that is.
  2. I do not know about the namespaces, but I would find it surprising if they are version sensitive.
I would suggest you find an error based on your expectations and then contact support, so we have some actionable use case we can work on. Since so far I do not find anything actionable, I will close the question for the time being.