Kevin, is there a way to get the tag to be included in the module.xml via the Maven build? I’m trying to find where I can configure that in the build pom, but not having any luck. Thanks!
The export functionality is not part of the supported/documented public api, so it’s not currently supported in the module plugin. The functionality does present some limitations/potential issues around gw stability, so I am not sure we want to support its wide use.
Cool, I can appreciate that… At least now I know it isn’t just something I’m not aware of… I think for my purposes I can wrap the required functionality so I don’t need to expose libraries at the root level… Thanks!
Ant to the rescue! But yeah, don’t do it. You can make a script module with static public final Class<?> variables set to the .class elements you wish to expose. Much safer, and gives your user short names for those classes.
Hi Kevin,
I am using the pubnub jar file in my gateway scripts on script playground. I took a short cut and just copied the pubnub jar file in lib/core/gateway folder. For Ignition 7.9.10 it works fine immediately after copying the jar. However for Ignition version 8.0, it didn’t work! I had to restart the Ignition gateway then it started working! Why in Ignition 8 it requires a restart of gateway? Restart is undesirable as it will interrupt a running gateway server ! How can I avoid it? By writing an empty gateway hook that references (imports) the one of the libraries in the jar? Is there any other simpler way without having to build and install an Ignition module?
Hi @Pramanj, I’m curious how you achieved this.
I’m also testing on a 7.9.10 install and was unable to import the Logger.class as a test.
I tried dropping pubnub-3.4.jar into the lib/core/common directory. When I ran from com.pubnub.api import Logger in the script console I got ImportError: No module named pubnub
I’m trying to learn more about these areas of Ignition so any insight would be greatly appreciated.
My end goal would be to achieve exactly what the OP wanted to do with regards to poi-ooxml-4.1.0.jar.
My idea is to get this jar working as you described, then trying to build a module for it.
I was able to get this to work.
I used pack200 to create a pack.gz and placed the jar and the pack.gz files in the lib/core/common.
I restarted the gateway and my designer and I was able to run from com.pubnub.api import Logger without any errors.
Thanks to @Kevin.Herron in this post: Adding java custom classes to Ignition
NOTE* his disclaimer about official support and the SDK is the way to go.
I placed my jars in gateway scope and I was able to access thru gateway scripts in 7.9.10. However for version 8, I too had to restart the gateway and designer once for it to work.
Are you using these jars from modules or from scripts?
Of course sdk is the recommended way but a dreaded the whole process of building empty modules and keeping versions of it for each version of Ignition. So I took the shortcut and it worked (atleast for 7.9.10)
Then don’t build empty modules. Put the jars you are deploying into the modules like they’re supposed to be, with a script class that exposes the import objects from the jars in the Ignition system.* namespace. You should do the work to make it easy on your potential customers. Don’t make them responsible for placing jars in the right places. They might not have convenient filesystem access, but be able to use the module install page in the gateway.
But I don’t have any modules ! I simply have jython scripts in gateway that use the libraries from this jar! If at all I have to build a module in gateway scope, then I have to use the skeleton gateway module that’s auto generated by maven archetypes for Ignition, and import some functions from these jars without using any of them it it and build the module! That’s what I meant by empty module. I hope my point is clear, or I am missing something?
Not clear! I am including an import statement in the skeleton module which uses some of the functions from this jar. Hope that’s what you mean? I am actually not using any function in the code of the module.
I guess I will have to eventually make such an empty module and try to Install in Ignition as a regular module which will install the jars in appropriate directories. The biggest advantage besides users convenience is that they can be installed in gateway without having to restart it!
Scripts. I’m working my way to building a module for it so users can use the system.* namespace in there scripts.
My end goal is to expose the apache poi 4.1.0 to end users. I’ve been digging around the forums and I’m wondering if my end goal is not possible? Kevin mentions a weird corner case about possible conflicts with the reporting module because it uses poi-3.14.
I’m looking for a kick start in the right direction (Uninstalling the reporting module isn’t an option for our client); is 4.1.0 not a good idea because of the reporting module? Is it a safer bet to use the same version as the reporting module? Is it possible to just access the existing POI library from all scopes?
Yes, you’ll have to use the same version as Reporting.
Only if your module adds it to all scopes. It’s added to C/D by Reporting, not gateway.
How come import org.apache.poi fails to import in the designer if the reporting modules adds it to the D scope?
I would think it’s possible since there already exists a third-party wrapper module for Apache POI, by Perfect Abstractions: http://blog.perfectabstractions.com/2017/04/05/using-the-pa-office-document-module/
His office module uses poi version 3.14.
I don’t know. What exactly are you trying to import and where?
From the designer’s Script Console:
from org.apache.poi.xssf.usermodel import XSSFWorkbook
returns
ImportError: No module named poi
Do you have the Reporting module installed?
Also: XSSFWorkbook is not part of poi-3.14 jar
Yes, the reporting module is installed.
If this is not apart of 3.14 then the Perfect Abstraction module must be using a different version.
The link above from @bfuson has sample code that uses XSSFWorkbook.
It’s not using a different version, you can unzip it and look yourself. It does include additional poi jars, though…
Thanks for your patience Kevin. I’m following now.