ST6RI-823 Support extending Jupyter integration with additional magic commands

[ujhelyiz]

This PR introduces an alternative way to register new magic commands to the Jupyter kernel: one based on the Java ServiceLoader mechanism. This extension allows external users to define and register additional commands that can reuse the state of the Jupyter kernel without needing to recompile the existing codebase. New commands are to implement the IMagicCommandRegistrator interface and register the implementation to the ServiceLoader. After that, the JAR file(s) containing the extension(s) are to put next to the kernel binary in the installation.

To handle these additional JAR files, the kernel descriptor file is updated not to rely on a specific JAR file but load all JAR files from the folder. This resulted in a simplification of the Jupyter kernel POM file, as it is no longer required to add the final JAR file name in the kernel descriptor.

[seidewitz]

I have never seen the word "Registrator" used before, but I looked it up, and it turns out it's a real thing. However, wouldn't "Registry" be the more common term to use in an Eclipse context?

[ujhelyiz]

I have never seen the word "Registrator" used before, but I looked it up, and it turns out it's a real thing. However, wouldn't "Registry" be the more common term to use in an Eclipse context?

I think the Registry name would be misleading, as the role of the Registry (one who stores the separate entries) is handled by (1) the class Magics and (2) the class SysMLInteractiveHelp - those are the ones storing the registered commands and help texts, respectively. My thinking was that the new registrator classes are responsible for calling the "register*"-like methods, like registerCellMagic or registerLineMagic or registerHelpStrings.

The alternative I was thinking about was a CommandProvider interface, where the specific classes implementing the LineMagics (and maybe one or two specific interface methods for the help texts) are returned. I decided against this approach as the Registrator approach does not specify that LineMagic commands are returned but could be CellMagic as well, and it also allows some custom logic to decide what commands to add. While there are no requirements for these capabilities right now, I was aiming for a more widely useful extension approach here.

[seidewitz]

The alternative I was thinking about was a CommandProvider interface, where the specific classes implementing the LineMagics (and maybe one or two specific interface methods for the help texts) are returned. I decided against this approach as the Registrator approach does not specify that LineMagic commands are returned but could be CellMagic as well, and it also allows some custom logic to decide what commands to add. While there are no requirements for these capabilities right now, I was aiming for a more widely useful extension approach here.

OK, I see. The name "Registrator" does seem to make sense, as odd as it sounds!

[seidewitz]

The org.omg.sysml.jupyter.kernel/installKernel.sh script no longer works. It ends with

--- Step 4: Installing kernel ---
python: can't open file '/Users/seidewitz/Documents/Work/git/SysML-v2-Pilot-Implementation/org.omg.sysml.jupyter.kernel/./target/kernel/install.py': [Errno 2] No such file or directory

[ujhelyiz]

Thanks for pointing out this error; it was caused by me not running a clean build on my computer, so the output files were out as expected. I have pushed a fix.