nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Upcoming changes with 2024 R2

medini_1024169437

As usual, each upcoming release will bring a few improvements, fixes and changes for scripting, reporting and generally customization. With this article I would like to teaser a bit what’s coming.

Rhino JavaScript Engine
Update

We at last
managed to upgrade to a new platform version, including JDK 17 and with that a
newer version of our beloved Rhino engine. We were stuck for years on version 1.7.5
from last decade (2015). Now we moved to version 1.7.10 – still not the latest
but we are at least moving. That upgrade comes with a price: some features are
not working as before for example Array.concat() got broken for some reasons. I
suggest checking your scripts with the beta version and use a polyfill in case
you are affected. In addition, the pragma ENHANCED_JAVA_ACCESS is not supported
anymore by the engine. We had to workaround it and all test cases for script
libraries we posted so far seems to work but downloading the latest versions
may be required.

Script File Handling

The file
handling changed completely with the introduction of the medini collaboration
server in 2023 R2.1. There is a good read in the forum from Nils. That change basically implied that many well-known
features got lost, as they all were working on files and not on documents. Now with
2024 R2 we try to bring back some of the beloved features. You again should be
able to move script documents around, or even manipulate on file system and
then synchronize them with the model browser. Also, the possibility to create a
symbolic link in the navigator to a script location outside the project and
then sync should work.

API Changes

There are
as usually changes to the scripting API but not too many. You can create a
Stopwatch object at any time using Google’s Guava Stopwatch for example to
measure execution time in scripts. The modification of internal object
identifiers as medini identifier is forbidden for all scripts from now on.

M2Doc Reporting

Two changes are noteworthy for m2doc report
designers. With 2024 R2 it finally should be possible to access FMEA and FMEDA
metrics with parameters. In addition the general purpose eval() service is now
(1) applicable to any type of object, so also non EMF/Medini object and (2) accepts
up to 5 parameters which can be used in the evaluation script. With that is
should be possible to at least script anything that is missing for the report.

Final and more information will be available in the final documentation.

Happy Scripting

Jan

Find more posts tagged with

medini

medini legacy

Accepted answers

All comments

medini_1024169437

I forgot to mention one small but maybe important detail: 24.2 will not have an internal, embedded JavaScript editor on board anymore. Main reason is that the eclipse project that has developed and still is developing that editor has done dramatic changes, e.g. introduced a node.js internal language server and that alike. We were not able to adapt to all changes, resp. were hesitating to get all implications on board.

So we decided to drop internal JS editing but rely on better and more and more often used external editors as VIsual Studio Code. I stringly suggest to get hands on that tool and start editing JS with code.

medini_1052680584

Hi Jan,

Thanks for the update. Even though I can understand the motivations, I was particularly worried with

"The modification of internal object identifiers as medini identifier is forbidden for all scripts from now on."

since control over the medini identifier is very useful for comparison of projects. For example, if there is a change

in the medini version, we can check if the script is still doing fine by doing a diff between the new and migrated files after the script. But unless we have control over the medini identifier (when the script, for example creates an element) and give them a meaningful and unique name, the diff will always show that there are many differences, simply because the medini identifier is different, although everything else is identical.

Would there be a workaround for that? Can one for example ignore medini-identifiers-only-differences in a diff?

Thanks for a feedback, Andre

medini_1024169437

Hi Andre, good point. What kind of models we are talking about? Are you creating mainly system models?

We of course still have the comparison also for models imported from external sources as EA, Rhapsody etc but changed the way of comparing them so that the external unique identifier is not anymore directly written into the created element (that one gets a unique ID) but annotated as an "external sync id" to the element. The comparison then takes care that two elements with same external sync id are treated the same, even if they have different medini identifiers

So the script "just" has to annotate the created elements the right way. I need to double check whether this is made available to scripting but need to know which type of models you are creating.

Happy Scripting

Jan

medini_1052680584

Hi Jan,

Yes, for imported system model elements there is this way around.

But we deal more with elements created by scripts themselves, specially FTA events.

We create a lot of trees with scripts, and it turned out that is very useful to create these

events with "controlled" (yet unique) medini identifiers.

This also makes the diff easier, when comparing two projects where the script ran: if the

medini identifier were always chosen randomly, the diff would show all the created elements as deltas,

although only the medini identifier is actually different.

Furthermore, as mentioned on my previous post, it is also useful validating

the script in new medini releases.

Thanks for taking a look!

Cheers, Andre

medini_1024169437

Ok, that is important to know, so you apply this also to non-system models.

Let me check and get back here asap.

Jan

medini_1024169437

Btw. I also forgot another change to mention: the Rhino engine has to cope now with much restricter Java engine 17 and for that reason the $ENHANCED_JAVA_ACCESS$ pragma (resp. the underlying feature in Rhino) is not available anymore. As a consequence, it is not possible anymore to access non-public operations and attributes. While this might be no issue for most of you, some scripters may have used the flag. Or you have used it without recognizing the implications. You may try to switch the pragma off in current medini to see whether your script would still run to check.

Some of our own libraries are affected but we will try to change 24.2 in a way that the script do not need that flag anymore.

Happy Scripting

Jan

medini_1024169437

Andre,

I tested what I proposed and it works for sysml, measures and a few others but not for FTA (excluded).

Could you list the types of elements you create that need this fature?

Thanks you

Jan

medini_1052680584

Hi Jan,

The FTA elements we create per script are typically

Metamodel.FTA.Event, .EventNode, .TransferGate, .LogicalGate, .VotingGate, .Connection

As I understood, elements with equal "sync id" would be considered the same by diff&merge, even if their

mediniIdentifier is different. This is would be a very helpful feature, assuming of course one can modify "sync id" per script.

Regards, Andre

medini_1024169437

OK, so basically FTA Metamodel, nice. Thanks Andre, that should be feasible. It is was basically a matter of performance that let us limit the amount of checks in the past to just a certain number of metamodels.

And yes, a script can easily set that annotation, I already verified that.

Jan

medini_1063548292

<?WORD FLAGGED?> Jan,

One question related to Rhino .. You are planning to use the VERSION_ES6 flag for the script context>

Just asking because I was reviewing Release notes and the Compatibility info of Rhino and there ar some features that are conditioned by that version. For instance apparently it introduces for .. of but also impacts the Array.concat .

Thanks,
Marian

medini_1024169437

Hi Marian,

we will not enable VERSION_ES6 by default but instead offer a new pragma $VERSION_ES6$ so you can switch to that version if you want yourself.

We decided for this solution after some discussion and think this is a good way and "pragmatic".

Happy Scripting

Jan Mauersberger

medini_1063548292

HI Jan,

One question related to the general Collaboration server stuff.

I wonder whether it is already possible to configure the Medini project template (Tool Preferences->Templates) with a reference to the Collaboration server project?

Is it already in (current release 2025R1) or planned ?

What is the proper way how to configure URL/syntax?

Thanks,

Marian

medini_1024169437

Hi Marian,

thats not yet possible but planned.

Regards

Jan

medini_1052680584

Hi everyone,

My team is intending to migrate to the v2025R1 and I am doing some tests.

Jan wrote:

"You again should be able to move script documents around, or even manipulate on file system and then synchronize them with the model browser. Also, the possibility to create a symbolic link in the navigator to a script location outside the project and then sync should work."

I need to catch up on these changes (I really liked the old embedded Javascript editor though ) so

I checked some articles in the forum. It seems the best way to proceed is to link the config/scripts folder

to an external folder. Unfortunately I could not find any article describing how to do that (without using mklink, which needs admin rights).

Can some please help me with that?

Thanks!

Regards, Andre

medini_1024169437

Andre, for that you have to open the "Project Explorer" (formerly known as "Navigator"). Navigate in your project to the config folder and create a new folder inside:

Important now is to use the "Advanced" section and "Link to alternative location". Name the fodler scripts:

Once done, switch back to the Model browser, select "config" package there and "Synchronize Documents".

Jan

medini_1024169437

Ah, and another article: Using symbolic links to manage scripts outside the project : Ansys medini analyze Support

medini_1052680584

Hi Jan,

Back to the topic of the sync ID. I understood we can use annotations for setting a user specific ID, which is then taken into account during diff&merge.

Do you have a snippet of how exactly that annotation can be performed, such that diff&merge will check there in order to decide if they are the "same" element in the two projects being compared?

Thanks!

Cheers, Andre

medini_1024169437

Andre, before writing anything technical, that sync id was specifically introduced for objects that were imported from external tools like requirements or system architecture tools as those tools typically have their own way of unique identifiers and users may import them independent from each other.

Do you have such a case? or are you working with "general medini created objects" which you would like to make "the same".

Jan

medini_1052680584

Hi Jan,

I am referring to our previous discussion in this post.

Basically I want to be able to create FTA elements in two different projects, but if
I do a diff between the projects, the diff knows they are the same element.
Chaning mediniIdentifier made that possible. Now I think I need to use this sync id mechanism,
since mediniIdentifier cannot be changed anymore.

Regards, Andre

medini_1024169437

Thanks for the reminder. I have to double check myself. Last tie I mentioned that FTA is not supported and I am not sure whether things have changed. In addition I can dig out the script that does the annotation so you can find our yourself, if that's okay.

Jan