I’ve spent two weeks learning how to get a stub module compiled and installed on the Ignition gateway, using in the Ignition Maven Plugin. I’ve spent three weeks total, as I spent a week in the Eclipse/Ant environment before I found out about the new SDK and Maven. For our company, three weeks of an engineer’s time is a big investment just to get us to the point where we can begin our evaluation of Ignition.
Inductive Automation can ease the transition to Maven by including its own introduction to Maven in the documentation of the Ignition Maven Plugin, rather than referring the reader to the Maven five-minute introduction. The critical terms “project” and “module” have different meanings in Maven, the IDE, and Ignition. This leads to confusion. The confusion is compounded by the less-than-precise usage of “project” and “module” in the Maven documents, and even in the top-level pom file. The confused developer is forced to resort to google searches, which muddy the water further by inconsistent usage of terminology.
IA can avoid all this confusion and lost time by explaining how Maven, and the Ignition Maven plugin, go about compiling code and building the modl file, making the correct distinctions between “project” and “module” in context. Special care is needed when discussing the projectScope and depend tags in the configuration section of the plugin declaration. I did figure out projectScope–it does what I thought the depend tag would do. I have no idea what the depend tag does, as “fpmi” appears nowhere else in the document.
Inside the plugin configuration the element is used when your module depends on another Ignition module, which is the case for things like components (which depend on Vision) and drivers (which depend on UA). “fpmi” is the module id for the Vision module.
Much of the configuration of the ignition-maven-plugin is simply mirroring the module.xml that was previously maintained by hand. The other less obvious bits, such as s, are so the plugin can gather your dependencies and list them in the module.xml it generates as well as make sure the necessary ones are actually packaged into the modl file.
Transition to Maven seems to have put a damper on the development process! We were used to the previous approach when everything was self contained and we could figure out what libraries are required and what are missing. Perhaps Maven approach is more suitable for large projects where 100’s of developers are involved and you need a continuous delivery for every commit. Where as here we are dealing with modules developed mostly by individual developers or small teams.
Hope we will get used to the new development process soon.
Prafull
Developing with the Ignition “SDK” is just like any other Java development. It’s just a set of dependencies. There’s no magic.
The only thing in the whole process that is Ignition-specific is the packaging of a modl file. However, if you read the programmers guide you’ll find that the modl isn’t complicated either - it’s just a zip file with an XML descriptor that tells us what jars to load in what scope and what your hook class(es) are.
You can use any tools you want if you understand that there’s no magic.
In fact my module is already developed and tested with version 7.7.8 and requires no chnage for the 7.8.3 version, but I was just trying to get used to the new SDK. I was doing some other development work so couldn’t concentrate much on the new SDK. Its perhaps my own mental block, will get over it soon.
When three development tools (IDEA, Maven, Ignition) use the same critical terms (project, module) to refer to different things, and when the documentation for one tool (Maven) is less than precise in its use of the terms (reader is left to infer that module is a subset of project; sometimes project is used when speaking of module, the reader being unaware), and when the documentation for the primary tool of interest (Ignition) leaves it to the green developer to sort through all this overlapping terminology–well, then it sure does seem like one must be a magician to make it work.
I’ve started from scratch in some dozens of programming environments over the years. This has definitely been one of the more confusing to get started. I had Eclipse and Ant building a stub module in two days. It took two weeks to do the same with IDEA, Maven, and the Ignition Maven Plugin.
Yes, some of the terminology is definitely overloaded at this point. Much of the documentation was written before we started using Maven and it needs some attention from us.
[quote=“xasga”]
I’ve started from scratch in some dozens of programming environments over the years. This has definitely been one of the more confusing to get started. I had Eclipse and Ant building a stub module in two days. It took two weeks to do the same with IDEA, Maven, and the Ignition Maven Plugin.[/quote]
Sure, the ramp-up time for using Maven is going to be longer if you’re not already a Java developer. The point of my previous post was that you don’t need to do it that way if it’s not “clicking” for you. You could stick with Ant or use any other build tool you want.
All you need is to somehow produce a zip file containing a module.xml and the appropriate jars. Any build tool can do that. Or don’t use a build tool at all. A simple shell script and a manually curated module.xml file would suffice.
[quote=“Kevin.Herron”]
Sure, the ramp-up time for using Maven is going to be longer if you’re not already a Java developer. The point of my previous post was that you don’t need to do it that way if it’s not “clicking” for you. You could stick with Ant or use any other build tool you want.
All you need is to somehow produce a zip file containing a module.xml and the appropriate jars. Any build tool can do that. Or don’t use a build tool at all. A simple shell script and a manually curated module.xml file would suffice.[/quote]
I considered sticking with Ant. You pointed out, correctly, that I would be swimming upstream a bit. In the long run, it will be easier to keep up to date, and get support, while working with the same tools as the developers of the system.
IA is looking to bring more system integrators into the fold. Few integrators (it seems to me) are java developers. Making it easier to get started is in the best interests of all concerned.
[quote=“xasga”]I considered sticking with Ant. You pointed out, correctly, that I would be swimming upstream a bit. In the long run, it will be easier to keep up to date, and get support, while working with the same tools as the developers of the system.[/quote]You wouldn’t be alone, though. I’ve decided to stay with ant for modules I support targeting v7.7 & v7.8. There’s just not enough advantage (for me) to restructure my project repos for maven.[quote=“xasga”]IA is looking to bring more system integrators into the fold. Few integrators (it seems to me) are java developers. Making it easier to get started is in the best interests of all concerned.[/quote]Well, I would argue that writing modules in Java for Ignition is way past the “getting started” phase. I would further argue that advanced Jython scripting skills in Ignition, where one is comfortable scripting Java objects and interfaces, is the best way to prepare for the intricacies of the Java side of the Ignition platform.
I considered the scripting route. Our long term needs are best met with modules, for a variety of reasons, so our evaluation must center on the module. (Though I can appreciate the advantage of starting out with scripts, if one has the time.)
"Getting started" is in reference to building and installing a simple stub module. Just a few lines of the code are my own; the bulk is from an example. The code was done in an hour or two. It shouldn't take two weeks to build and install the equivalent of a "Hello, world" program.
Java modules v/s Jython approach looks analogous to Invasive v/s non-Invasive surgery to me. Anyone would prefer non invasive approach provided it meets your requirements. The question is, does Jython allow you to do everything that you can do with module approach? And what about efficiency? For my modules I am not sure if Jython will do the job (mostly reading/writing to ignitions tags, socket communication with external programs etc). But its worth trying non-invasive approach even if it is at the cost of slight loss in efficiency (Especially with Ignition’s newer versions becoming bigger and more complex).