I’ve installed the Ignition Module SDK, and am setting up for development using the Eclipse IDE. Before I get too deep into this, I would like to be sure I will be able to work efficiently in the long run.
Two functions that may be issues down the road, if I keep using Eclipse:
Using one specification for dependencies. Reading the Ant build file, and running the Eclipse app, I gradually realized that there are two builds going on: the Eclipse build and the Ant build. I have seen several people in the google-verse talk about problems keeping Eclipse and Ant on the same page with regard to dependencies. Apparently there is a way to use IVY for this purpose, but it seems better to have one software tool handling dependencies than three.
Using a version control system. I haven’t used any version control system in the past, but have often wished I had. So I’m going to set things up right this time. Eclipse supports CVS, and (as far as I can tell) only CVS. From the CVS web site I gather that it has not been updated since 2005. NetBeans supports several version control systems, including git, which I believe is up to date and widely used.
Whatever IDE I use, it must support remote debugging of the module as it runs in the gateway. It’s not clear to me at this point that NetBeans supports debugging code running in the Gateway, although it does say it supports remote debugging.
Anyone have any experience with NetBeans, or other alternate IDE?
Opinions about Eclipse relative to alternate IDEs?
Also, you must be working off the old SDK package that you would download. Nothing is ant-based any more, we moved it all to Maven. The examples are now hosted here: github.com/inductiveautomation/ … k-examples
I’m using Eclipse here, and still using ant, too. Haven’t had any problems building for both 7.7 and 7.8, but Eclipse is like a comfortable old shoe for me. That might matter. Contrary to what you’ve heard, it does integrate git.
I’ve never bothered with remote debugging. IMNSHO, if you don’t have enough logging available to debug it when you are writing it, you won’t have enough to debug it when a customer calls.
I used Eclipse back in 2003, in a QNX environment. It was very clunky. It is much better now, but still not as smooth as Visual Studio. (VS has its own problems, but for what I do they rarely intrude into my workflow.)
Good. I'll look into this.
It is true that the debugger is useless after the fact, if the faulty behavior cannot be reproduced on demand. That can be a big problem in production. On the other hand, highly detailed logging would be required to ensure that the cause of any misbehavior can be identified from the log alone. Seems that adding such logging could extend development time significantly, reduce throughput at runtime, and require some infrastructure for storage of the log(s). (Perhaps the Ignition data logger handles the infrastrucure out of the box.)
I write machine control code in VB.Net for the PC, and for various PLCs. One of the big advantages of the PLC is the ability to examine the state of the system at any time. One of the big disadvantages of the PLC is the lack of any history, making it very difficult to see how the system arrived at its current state.
Perhaps the optimal approach is to use logging as if there is no debugger, to the point of disallowing use of the debugger during development, so as to force detailed logging. If it's a habit to write to the logger, perhaps it doesn't add much to development time. The really verbose logging can be turned off most of the time, so perhaps in normal operation there is good detail in the log without slowing down the process.
But I would also want to have the ability to view the state of the system via the debugger when the customer calls. Current state plus history is the winning combination, imo. And in a real pinch, the ability to step through the code is a big help, even though it interferes with the process.
Java has very configurable logging options, and Ignition has a nice wrapper in LoggerEx. Ignition starts up all loggers at the .info() level, and offers convient web & client UIs to adjust specific logger’s verbosity. When writing code, I put in many .info() logging points. I convert them to .debug() or .trace() later, and prune back any that are performance problems. .debug() and .trace() can be short-circuited to minimize runtime impact when muted.
Meanwhile, logging makes it possible to “see” sequences of events at speed and across multiple threads where a debugger breakpoint would impact time-sensitive external devices.
One of the other side effects of including many loggers is it forces me to make useful toString() methods.
I have IDEA and Maven installed. On the git site, I see the Ignition Maven plugin. There are two files, .jar and .pom.
I downloaded the jar file.
The pom file does not download. In Edge and Internet Explorer, I get “404-Request is marked as local-only”. In Firefox, the browser displays the xml text as a web page. I copied the xml text and saved to a text file.
In IDEA, when loading a plug-in from disk, only jar or zip files are accepted. I selected the jar file; the load failed. I zipped the jar and pom files into a single file. That also failed to load as a plug-in.
I don’t see the Ignition Maven plug-in when I choose “Install JetBrains plugin” or “Browse Repositories”.
You need to take a step back and learn the tools a little better.
You should be cloning the examples repository to your local machine. Then from there the example modules can be built by running ‘mvn package’ at the root of each example. In the target directory of the build project you should find an Ignition modl file if the packaging finished successfully.
These modules show you how you might structure your own module. Use them as a reference for how to setup your directories and your pom files.
The Ignition maven plugin is a plugin for Maven itself, not for your IDE. You can see a reference to it and how its configured in the pom.xml of each of the build projects, for example: github.com/inductiveautomation/ … ld/pom.xml
You can use ant, but you’ll be swimming upstream a bit. You’ll have to deal with packaging the modl file yourself as well making sure you have all your dependency jars in the right place.
Phil (pturmel) has, for better or worse, decided to continue using ant as well. I’m sure he has some good advice he can share.
Yes. At the moment, that looks like a much easier task than administrating a Maven installation. It may be that Maven is not such a needy child once it is properly set up. Even so, my concern is that we will forget the intricacies while it runs well, and then have to learn it all over again when changes are needed. Ant is clunky, but fairly obvious. A few paragraphs in an internal setup document will be enough to refresh the memory.
