There seems to be a lot of changes in the structure of classes and packages from version 7.9 to 8.1.*. For example package com.inductiveautomation.ignition.gateway.sqltags in 7.9 SQLTagsManager (ignition 7.9.3 API) (inductiveautomation.com) is missing in 8.1. Similarly the sdk examples given in older sdks (such as AbstractSimpleTagsProvider something like that) based on which we developed our modules are not present in the sdk examples architypes The old modules don't compile on new version of architypes. So, we will have to maintain separate version of our modules where ever its not compiling! Even if the example projects were maintained same across each version of architypes we would be knowing how to port our modules across all versions of architypes.
Its safer to use scripting functions to develop our module functionality rather than use a compiled and built .modl approach though compiled ,modl approach will be more efficient and desirable. We need better documentation for class files of Ignition than just javadoc !
Ignition follows semantic versioning. 7.9 -> 8.1 is a major version change (technically, a major and a minor version change). Both are 'allowed' by semantic versioning to make breaking changes, and you'll find that we actually strive to only make breaking changes during those version bumps. It is impossible to guarantee that a compiled module will work on multiple major versions, but as Phil can attest, it's very possible to make a module that supports a broad swathe of every patch version within a major/minor pair; e.g. you can compile against 8.1.0 and be able to run on every 8.1.X version. With reflection, you could even have 'progressive enhancement' as new features become available in new Ignition versions, though I would generally advise against it.
I don't know why you would ever expect a 7.9 module to "just work" in 8.1. Similarly, you can absolutely expect your module to have to be restructured to some degree and absolutely recompiled to run on 8.3.
I am not expecting my older version of modules to work on newer ones (especially with major or minor version changes), but even to port to new versions of sdk I should know where the packages have moved to or gone, and what alternative packages I must use instead! (for example the SQLTagsManager (ignition 7.9.3 API) (inductiveautomation.com) is missing in 8.1) We have to rebuild our modules for new major or minor versions when they break, we have to know how the old examples are to be rewritten with the new libraries. Though modules are more efficient than scripts , but scripts are easier to port across major/minor version changes and are well documented. Same examples for all sdks would have helped us in understanding the changes better perhaps.
Well, that's always been the deal. You can write a module, and get the benefits of static typing, deeper access to internals, obfuscation of your internal logic, and more control. Or you can write a script and be more within the 'guardrails' of what we provide. We don't really offer much documentation for the SDK outside of the Javadocs at present, though we're hoping to change that soon. A lot of it is that we just don't/didn't have the resources to do a good job of documenting things while we were also busy rewriting the code, and the SDK is not as immediately important to most customers as the software itself.
I expect the 8.1 -> 8.3 transition to be much better documented both for end users and for module developers than 7.9 -> 8.0.
It is understandable that your priority is delivery of the end product rather than sdk and its documentation! Although the scripting documentation is updated and well maintained as its part of the end product that you are delivering.
However, I was just thinking if these scripting functions are made accessible as java functions (they are internally java functions) through compiled modl files somehow, then it would be great! It would bring best of both the worlds to the end user as well as module developers. If the scripting functions can be accessed thru java programs in our modules then they won't break with version change as we would be using the well documented scripting functions and even if they break its well documented and we can easily do the changes in our modules that use them.
This will allow us to develop and test our modules using scripts and then compile them into .modl files for efficiency and security of our code. we don't need to understand Ignition architecture and complete javadocs and be an Ignition developer to be able to develop modules for Ignition. I hope I am making sense?
Sorry, @PRAMANJ, but module development has always been a moving target, and IA has always stated that its use is not officially supported. You have to learn on your own, and the level of complexity is such that I doubt a tutor would be much help. The examples, limited as they may be, are still the best starting point.
The most important thing is to start porting to new versions well before you need them. Almost all of my modules have been broken at some point by API changes, but since I've tried to keep up, each case of breakage was somewhat constrained.
You can, though the calling signature is going to change; some scripting functions accept plain Java arguments, but most, in order to accept keyword arguments from Jython, accept a PyObject[]/String[] argument pair that's extremely awkward to call from Java. It's usually more ergonomic, from code, to rely on the underlying API methods; but that then exposes you to the API surface changing across major versions. No easy answer.
I understand, IA should not be constrained by anything in developing new versions of Ignition. However, ability to write your own modules and integrate them in Ignition was a key differentiator and one of its USP's for Ignition as a product from other SCADAs. Exposing all API's with some examples for gateway, designer and client module was very attractive proposition to many developers they thought they could integrate their unique ideas seamlessly in Ignition easily! However its not easy to understand the API's and use them correctly, that too when they are ever evolving. Of course if your modules use a few handful APIs which you can upgrade with each new version.
I think it would still be worth the effort to develop such "hybrid" approach to module development, as it would bring us best of both the worlds - well defined and documented and UpToDate scripting libraries and JAVA native libraries such as JAVA's Socket libraries instead of JYTHON's or using any JAVA third-party libraries etc. Ability to wrap the scripting functions in a JAVA module and compile and sign and deploy as .modl file would also protect our IP which is missing in scripts.
It would be great if IA can include an example project in the example architypes to show how to call scripting libraries from JAVA however awkward they may be. Or simply add in scripting documentation few examples of how to call different types of scripting functions from JAVA.
Isn't that the nature of APIs though? They get built under the guises of convenience and security, and then, they continuously break the things that are dependent upon them with each subsequent refactor or "Improvement." More than once at the beginning of a project while discussing the creation of an API, I have asked the question: "Is this API even needed?" ...while simultaneously imagining all of the inevitable problems and ways to get around them. It's not a barrier to entry; it's just part of the job.
Still is. Ignition has a wide and varied collection of third party modules. And not just in the module showcase. That wide variety, and the large numbers of involved developers, refutes your implication that this is "too hard".
Whose effort? IA has their hands full developing formally-supported features. Efforts to support the SDK will take labor away from that. Considering the large job this would be, I don't see the same justification as you. If anything, I'd like to see IA flesh out the javadoc before any other SDK support efforts.
Don't forget that several people and organizations are developing useful modules in public. You could participate in those efforts as a learning exercise.
It's going to be a lifetime effort to master all APIs and it depends upon one's interest, motivation and need to learn them. It's not too hard if they are going to need and use them on regular basis.
Of course, effort on the part of developers to use the awkward calling of these functions from java. However, a bit of effort on the part of IA to give the concept behind it and a few examples of how to do it just to get developers started faster. It won't be much of an effort for IA as they are architects of these functions rather than we trying to figure it out ourselves by trial and error and groping in the dark.
The SDK hasn't existed but for a small fraction of a lifetime, and many people mastered large swaths of the API in a couple years of part-time effort. You can do it, too.
I don't find very much in the API that is awkward. It conforms very well to the java way of doing things. Your complaint essentially boils down to "I don't want to spend any time to learn, please hand this to me on a platter."
Even if IA hands out platters, no one will really be satisfied, because they won't have learned how to do anything without platter after platter.
Don't hold your breath waiting for IA to do this for you.
I just echoed what @PGriffith said about using the Jython functions from JAVA , not about javadocs, please see it in that context.
No that's not what I am saying! (You seem to have a lot of preconceived opinion about me!) I am just saying give few examples of what PGriffith said about the awkwardness the oddities and pitfalls involved in calling these Jython functions from java so that we can get started quickly and correctly instead of learning the hard way. Of course, we can learn it on our own by experimenting and this forum is there to for help as we can post specific problems when we do trial and error.
The maven central repository has 5 versions of Ignition repositories. Which versions of Ignition do they correspond to? Does building and testing our modules on all these repositories ensure its compatibility with all supported versions of Ignition?
Just to clarify, it's not my thread, I am not the one asking for a tutor, (in case you overlooked it). I just continued on this thread which was started by @ bkarabinchak.psi in Jan 2022.
I make it a point to read everything in the forum whether it's related to my immediate work or not because who knows when a nugget of knowledge will be needed. When it comes to an interesting SDK post, I almost always bookmark it for further study because often times, they tend to be specific, and I imagine that the generalized knowledge they will reveal would be difficult to find with a generic search.
In addition to the maven central repositories there are [javadoc for various] (Javadocs & Notable API Changes · inductiveautomation/ignition-sdk-examples Wiki · GitHub) versions of Ignition. I used the SQLTagsManager package in version 7.9 which was allowing all tag functions for Ignition, but for version 8 onwards this seems to be deprecated. Where can I find equivalent packages in these higher versions so that I can recompile my modules against the new tags library? the sdk documentation for 7.9 and the examples included samples for usage of these SQLTagManager libraries, where can I find documentation for the corresponding SQLTagsManager libraries in 8.0 onwards version so that I can chase the moving target and recompile my 7.9 modules?
