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; } } }

Execute script from commandline/headless.

medini_1039192772

I
would like to run a couple of existing scripts (javascript) that process
information in our medini analyze model from the command line (for integration
in a Jenkins CI environment)., but I do not know how to do this.

Find more posts tagged with

medini

medini legacy

Accepted answers

All comments

medini_1024169437

Hello Joost,

well, that's actually not possible with the current version. We are working on a command line option to execute scripts in batch mode (some addition to our "open" comment)

but with latest version 19.x there is no such option yet, I'm sorry.

Are these scripts just extracting information or shall they manipulate the projects?

Jan

medini_1039192772

Only extracting information. Manipulation from the commandline does not seem to be relevant for us.

medini_1024169437

Ok, that fits our assumption.

Do you want to concatenate the script with other command line stuff, i.e. you want that the scripts simply writes to STDOUT and pipe that into another process or is it sufficient that the script deals with writing the extracted data to a certain file in the file system?

Jan

medini_1039192772

The latter is what we currently do. The script itself opens a file for writing the output already. Any debug/error/warning messages currently go to the console. It would be nice if they would go to stdout/stderr but we can live without if needed.

If it would be faster to realize a solution where the script writes the output to stdout, then we can probably easily rewrite the script to do so. But that does not have our preference.

medini_1024169437

Ok, fits again, the later is easier because eclipse in general is writing stuff to the console and we cannot easily prevent that so output from the platform and from the script would be mixed together. What kind of input do you wan to pass to the script, it it sufficient to just access the medini project?

We plan to add that as an experimental CLI support to 2020 R1 upcoming release.

If you like, you can join our beta program end of October an test it and give us feedback.

Regards

Jan

medini_1039192772

The scripts have no parameters. They are not using a selection or other GUI related information. It is using the finder to walk over models in the project. A workspace may contain multiple projects, but the script should only run for a specific project, so it must be possible to confine the script to the scope of a single project.

Yes, I would certainly like to participate in the beta program.

medini_1024169437

Perfect, that fits the implementation. I'll notify you once the beta version is ready.

Jan

medini_1024169437

Joost,

the beta is ready. With that you basically can run a command like:

mediniAnalyze.exe script -f Foo.mprx Bar.mprx -s C:\temp\myScript.js -useDefaultWorkspace

Give me a ping and I can provide the beta version.

Jan

medini_1039192772

Nice! I look forward to receiving the beta version.

Will it be possible to supply a specific workspace as well? In the future I imagine we may have multiple workspaces on the buildserver.

medini_1024169437

Joost,

I uploaded a beta version to your account on our server (165***) you should know.

You can download and install it separately from any existing version.

The workspace is currently used to extract the mprx files, therefore you can use -useDefaultWorkspace,

its not used to actually scan the workspace for mprx files.

A slightly improved version:

mediniAnalyze.exe script -f Foo.mprx Bar.mprx -s C:\temp\myScript.js -useDefaultWorks -nosplash

medini_1039192772

Hi Jan,

I have tried to use the beta. Unfortunately I could not get it to work yet.

First I have upgraded (a copy of) our project and then exported it as a mprx file.
I have tried various ways use the commandline to run the script on. But they all failed:

No initial workspace at all: Nothing happens, only an empty workspace is created. No log. (license issue?)
Starting the commandline with the open command. Workspace is opened and project imported. After re-opening the workspace, the project is gone. When using this workspace to execute the script nothing happens. No log entries are added.
Starting the commandline with the script command while providing an invalid script filename. Workspace is opened and project imported. The script is not executed (obviously).
Starting the commandline with the script command while providing a valid script filename. with workspace from 3. Project seems invalid. The script is not executed (obviously)
The following entry is in the log:
!ENTRY org.eclipse.core.resources 4 567 2019-11-07 09:38:07.004

!MESSAGE Workspace restored, but some problems occurred.
!SUBENTRY 1 org.eclipse.core.resources 4 567 2019-11-07 09:38:07.004
!MESSAGE Could not read metadata for 'CISADAS_Logena_workspace'.
!STACK 1
org.eclipse.core.internal.resources.ResourceException: The project description file (.project) for 'CISADAS_Logena_workspace' is missing. This file contains important information about the project. The project will not function properly until this file is restored.
Add the project to the workspace manually, then run the command line. An error message is given that the project already exists in the workspace. The script is not executed.
Omit the -f option or provide an empty file. Errors are being generated, the script is not executed.

Also, I would like to propose the following two items:

* Could the import of the project be skipped, please? Instead I would like to specify the workspace location from the commandline. (e.g. like the CDT does with the -data option). The script could then run on all projects in the ws, or maybe specify a working set? Rationale: The current approach seems to make it harder to run multiple jenkins jobs in parallel and creation of the mprx file seems to be a manual step only? Which is exactly what we are trying to avoid...

* Currently the script is provided as an absolute path name. I would also like to be able to specify a "relative" name. Not relative in the filesystem sense, but relative to the project, since the script is already part of the imported project tree. So that we could specify the script with the same path and name as in the "execute" context menu.

Thanks in advance,

Joost

medini_1024169437

Thanks Joost for trying this out, highly appreciated.

Let me check your response more carefully in he next days and I will come back with a solution proposal here.

Jan

medini_1024169437

Joost,

I think there is a general misunderstanding of how the CLI currently works.

The CLI is currently solely created for MPRX files. That assumes that you never have projects in you workspace, the tool itself uses the workspace (any workspace) to expand MPRX files temporary only.

So creating projects in the workspace and then using the CLi on that is not foreseen.

Anyway, it should work if you have an MPRX anywhere on your filesystem (outside any workspace) and he n use the script against it. Could you try that at least one again?

The idea to support relative script path is very good and feasible I think.

The idea to also support "expanded projects in a workspace" (in addition to MPTX files) MAY be feasible too, although it countermeasures the initial CLI idea.

Anyway, lets drive this a little bit further.

Jan

medini_1039192772

I think I did/do understand the idea behind the MPRX files and how to use it. It simply does not seem to work for me yet, so then I started experimenting with various workspaces to see if that would help, and to see if I could get our current workflow going, but no ;-( it did not.

I have tried once more after deleting all my workspaces. Instead of executing the script the UI opens with the imported project closed. If I try to open it:

Which is essentially the same error as point 4) of my previous post. So something seems wrong with the import of the project or with that "default workspace" it uses.

I had already verified earlier that the .project file is actually in the MPRX file. And I have imported it manually without any problem.

It seems that my "default workspace" somehow already has an invalid earlier imported project inside when starting. Then it does no longer want to import the new project file and stops. Which is strange because if I start the tool then my actual default workspace show no project at all. I tried but cannot find the location of the workspace that it is using to run the script. So I am basically stuck.

medini_1024169437

Thanks Joost for further testing, highly appreciated.

The "Import project from MPRX/ZIP" into workspace is a bit more flexible than the double click actually,

mainly because because it can handle MPRX as well as ZIP - and it can handle sub-folders in ZIPs more flexible.

For MPRX we always assume we have created them so they should be okay. There should be a single Folder in the ZIP and inside he files.

Neither folder in folder nor files directly in the ZIP are supported. Could you check?

Maybe create a new MPRX out of your project and try again.

Note: if you use "-useDefaultWorkspace" the tool will create and use a hidden workspace.

Furthermore all CLI commands temporary unpack the MPRX and remove them from the workspace when closing.

I am working on improving the -script command to 1. also support existing workspaces (folders) and relative script paths into the project.

jan

medini_1039192772

Thanks for the information.

This is the structure of the MPRX:

I did already re-create the MPRX twice with the same result...

I am using -useDefaultWorkspace indeed. To me it seems that I managed to create a corrupted project in this hidden workspace that was not cleaned when closing. And now it is preventing me to proceed. If I knew how to clean this hidden workspace, then I expect it to work just fine.

medini_1024169437

Hello Joost,

thanks for the update. Some updates from my end:

1. the "hidden workspace" is typically located in the config area of eclipse, under Windows that is

> %USERPROFILE%\.eclipse\mediniAnalyzeConfig.20.1.0.XXXXX\openWorkspace

Please check there whether there is any garbage or simply remove the workspace.

2. I have improved the CLI so it can (1) handle relative script references, (2) can work with unpacked projects (basically project folders and (3) does not need any hidden workspace at all anymore. I will upload a version after some more testing later the day.

Happy Scripting

Jan

medini_1024169437

Joost,

i uploaded another beta release. Wit that you have the above mentioned features and you do not have to think about the hidden workspace anymore, its not really used. A command may now look like this:

mediniAnalyze.exe -nosplash script -s @project.dir/config/scripts/test.js -f C:\Temp\A.mprx C:\Temp\B -useDefaultWorkspace

B being a project folder. @project.dir is a placeholder for the project being scripted.

Jan

medini_1039192772

Sorry for the delay. I have been too busy with other things. I have now downloaded the new version and tried again. Unfortunately with the same result.

I can issue the command line just fine. The executable starts, but exits after a very short time. And no output was written. I also cannot find any relevant logs or console output.

medini_1024169437

Joost, this is odd. You picked the right package? I recognized that I forgot to delete the old one.

Should be: mediniAnalyze-x64-setup-2020_R1-191109223846-985d063-SAURON-DEV.exe

I removed the obsolete one.

Could you try to keep the Script simpel and maybe just use something like:

alert("Project " + self.name);
alert("Packages " + finder.find("isa", "PJPackage").size());

"done";

That should open some dialog to make sure the script is executed.

Jan

medini_1039192772

I did already made the script a lot simpler, but not simple enough ;-(

Your version works fine from the command line, but does not run from the UI.

Mine below runs in the UI (without the first line) but break from the command line.

alert("Project " + self.name); // This fails when executed on manually imported project (self unknown)
alert("Location: " + __filedir); // This fails when executed on command line
alert("Packages " + finder.find("isa", "PJPackage").size());

"done";

medini_1024169437

Thanks Joost,

that's very cool feedback, I see much clearer now, the available variables are different in the two modes.

I will check for a solution and post some reasoning later.

Jan

medini_1024169437

Hello Joost,

I think we can provide all the __XX variables the same way as when executing via menu.

The new execution path simply did not anticipate that a script could executed from within a project.

What about the "selection" argument Its typically used when executing scripts "interacively" but doe snot make sense

in batch mode. Or doe sit make sense to always pass the project root node as "selection"?

Thanks

Jan

medini_1039192772

For scripts that will run from the command line we will not be using "selection". Using the current project for selection might help others though. I guess you could also throw an error if a script uses it to avoid getting unexpected results.

medini_1024169437

Joost, an initial version of this features was released wit 2020 R1.

Happy Scripting

Jan

medini_1063548292

Hi Jan,

I have tried the CLI ( also because it now supports collab project option)

I have couple of questions

I provided the folder with multiple mprx /zip files /folders representing projects.I t seems like this is not supported right? one has to generate those and provide them on a command line individually per each project after -f.
the context is still missing all __* variables.at lest __homedir and __ tool.* would be quite handy to have
Using some interactive stuff dialogs from ui.js dos not work correctly.
strangely the alert works but others based of workbench shell are not displayed and prematurely exits because of null shell.
interestingly, the dialogs based of jface's Message Dialog (MediniDialogUtil) are working fine with null shell Is there some explanation to it ?(see attached script)
What is the example of a command line for a collaboration server after -u ?

Thanks,

Marian

medini_1024169437

Hi Marian,

I try a short reply:

1. there is no support to pass a folder as parameter but you can pass multiple MPRX files and URls on command line, -f and -u accept mutiple parameters

2. hm, strange, you are right, there was areason for that I dont remember... let me check, in worst case we have to add that (at least some of them)

3. headless mode is somewhat special, there is no visible workbench window but some parts of eclipse are ramped up. And as you wrote, some UI bundles work without any root shell, othres dont. Do you really wan to use interactive stuff in batch mode? Assumption always was that any script run via CLI is running headless and in most cases without any user interaction

4. if you have a project open in the portal (the project overview where you add collaborators etc.), just take that URL and pass it on CLI via -u

Hope that clarifies most questions

Jan

medini_1063548292

Thanks Jan!

So executing scripts on multiple thingies need a list of paths/urls I tired use wildcard trick PATH_TO_PRJS/* but did not succeed.

medini_1063548292

Hmm ,

I just noticed that 90 % of my reply was just cut-out. I Will try to r restate it

Continue... So since my "simple" hack thinking to using wildcard was not successful I will have to use all the paths as an argument, Hoping that there is no CLI command character length constraint

A suggestion & Question:

Would it be possible to automatically delte the contents of the temporary ProjectCompareInput folder that is created for each project on the command line ? With large number of projects to can quickly use up some disk space, and need a manual attention to remove it:) Would it be possible to marke it for deletion like it is done for tempFile ( deleteOnExit())?

W.r.t __* variables, here at leas __homedir is necessary to allow using load("~"), the __tool versions should be also quite easy to ( provided that the required bundle is avialabe in script mode)

Headless mode : Thanks for clarification, indeed the main goal is not to interact with users. but there could be cases. It was just the fact that I wanted to use some debugging dialogs to see the potential problems and steps of the scripts using dialogs. Why Dialogs? I was trying to find a way wo to perform a textual verbose but have not found any way (console.log , eclipse log , System.out.priint , command line) The only way was to create a File and write the text there.

I wanted to have clarification on the workbench shell as my initial idea was to perform some actions that may require workbench and will fail without notice. My initial dumb idea was to use script to :

Perform sanity check -> possible through SanityUtil in JS
Perform Validation ( Constraints) => To be tested
Generate reports ( M2doc , BIRT) => To be tested
Export diagrams => To be tested

So due to the workbench decencies some of the bundels might not load/wrok correctly. I noticed that during trying to bind the class into the JS and it failed ( An error occurred while automatically activating bundle XYZ)
Question:

I guess the workbench shell is not possible to replace the SWT's shell as argument, right ?

I was able to pop-up the JS debugger . so at leas t that javax.swing seems to work. At last some way to enable debugging

So the server projects -u can only be used with open, diff command.

I was more aiming on script -u i, this one is able to handle collaboration related bundles as they are some dependencies on UI ?required to login, fetch project data ? No "interaction free" method to login, download the Collab project data ? I had some ideas in mind that could be done but maybe you already has this on the roadmap ...

Thanks,

Marian

medini_1024169437

Thanks Marian, a few comments:

- yes, no wildcard support. maybe we can do it like other programs in these situations: instead of passing hundreds of file paths or URls, you can pass a file and inside the file are the MPRX file names and URls

- yeah, that deletion is tricky, we mark already the folders with delete on exit but Java doe snot delete folders if there is at least one file left, we have to mark all files inside as well I recently figured. will improve, promised

- got that. I think the orignal issue was (and still is) that you can either use a script file that is outside any MPRX or you can refer to a script *inside* the MPRX, and we were not able to support both use cases, but I might be wrong

- I think we can generally improve partially but you will never have the same full fledged environment as with an eclipse workbench up and running, but dedicated use cases can be iproved for sure

- either shell is okay in SWT I guess, does not have to be the workbench shell

- ah, you are right I overlooked thatno support for -u in scripting (yet)

Jan