Looking at the buildscripts, I think you’re missing a key part of the module plugin: the
toModl dependency configuration, used in place of ‘implementation’ or ‘compile’. This configuration is required to ‘mark’ the dependencies for collection and inclusion into the final modl file. It also adds the dependencies to the module.xml that is generated. So you can change
implementation dependencies to
toModl and see if that fixes the issue.
That said, the plugin you are using (and indeed the one used in our sdk examples) is on the way out and won’t see any further development. It’s not usable for more-current (7.x) versions of gradle due to the use of deprecated/removed apis, and it doesn’t support all the latest features.
My suggestion would be to migrate to the ‘new’ open source plugin: https://github.com/inductiveautomation/ignition-module-tools/tree/master/gradle-module-plugin
The configuration is quite similar, but will require some changes. The benefits are that it’s open source, uses/supports current versions of gradle (as well as more recent gradle features such as incremental assembly and build-caching), and will see continued support/development. It’s not yet at its first ‘final’ release version, but it’s published to the Gradle plugin repository and we’re using it internally for builds, so I feel pretty comfortable suggesting it in place of the ‘old’ one. I’d also suggest migrating
build.gradle.kts as I find it’s much nicer to deal with, but it’s not strictly necessary.
The new plugin, similar to the old one, uses ‘custom’ dependency configurations to mark implementation or api dependencies that should be included in the modl (use the
java-library plugin instead of plain
I haven’t quite finished testing the changes made to switch out the plugins on the public sdk examples, but you can see it on this branch if you’d like to see example configuration.
But take a look at the README on the new plugin/“module tools” repo and let me know if you have any questions.