I am looking at using Gradle instead of Maven for module development, and I have been looking around but haven't found anything obvious.
Is there a way to do the post goal provided by the Maven plugin from Gradle?
As of ignition-maven-plugin v1.0.8, there is also the post goal. The post goal takes the modl goal one step further and acts as helper goal to "post" your packaged modl file to your running developer gateway. Note: You'll need to specify a <gatewayAddress> in the plugin configurations if you are not using the default (localhost:8088).:
If I had to guess I am sure that its just an http POST of the modl file to a web endpoint, but I can't seem to find that endpoint in any documentation.
In the same vein as this, trying to use the module generator to setup everything so that I don't have to figure out how to add that task to my gradle wrapper.
In parallel to this (maybe @PerryAJ will know this as well) it looks like the current Gradle plugin does not support deployModl as mentioned above.
When listing out the tasks it supports a post task, but it posts it to system/DeveloperModuleServlet instead of main/system/DeveloperModuleServlet and fails. Upon trying to change/build/use a copy of the plugin from Github it looks like it’s potentially a completely different plugin than the one currently on the nexus repo (v0.1.0 vs v1.2.0-SNAPSHOT on nexus)
I am curious if there is a public repo location for the version 1.2.0-SNAPSHOT that is currently published, that I could create a request to change the servlet endpoint to.
Interesting. When we try to post to a dev gateway with the existing one we get a java io file exception that a file does not exist at http://localhost/system/DeveloperModuleServlet. We did change the gatewayPort to 80 (what it is on our system). Any ideas?
This thread just came to my attention. Getting caught up a bit, but some quick clarifications:
The plugin you are using with the 1.2.0-SNAPSHOT version is the old (and not-open sourced) plugin - it's not available as open source, unfortunately. That plugin is something we host on nexus only to avoid breaking builds that people have established with it, but that plugin is EoL (internally it is using APIs that have since been deprecated and will go away in gradle v8).
I'd highly suggest migrating to the rewritten open source version found in the ignition-module-tools repo. That one is a full rewrite that was done using modern Gradle apis, and published to Gradle's central plugin repo (so you don't need any special repository configurations for it to resolve). We use it ourselves. We'll be continuing to develop/maintain that one as necessary, so feel free to open issues/PRs on github for that.
May have been a mistake to not go with v2.0 for the new one, but the two plugins have totally different plugin IDs and have effectively 0 in common aside from high-level behavior and similar configuration models (should be a few minutes to migrate old config to the new one though). See the Plugin Page for plugin ID information.
Last I tried, I was able to succeed with deployModl (and apparently didn't remove a //TODO comment when I finished the implementation), but it's not a normal part of our workflow so I haven't tried it for a couple months. I'm going to fire up 8.1.18 locally and see if I hit any issues trying to use the deployModl task, and will clarify what configuration was required (assuming it works).
Re the generator: it should still be functional if you run it locally, either via gradlew runCli in the generator project, or by building the binary for your local system via gradlew :generator-cli:nativeImage from that same directory. The generator is definitely ripe for some updates and release automation. I'm hoping to spend some time on that prior to ICC, but can't promise anything.
Just tested the current version of the open source plugin against Ignition 8.1.18 release and deployModl worked. Tested against Ignition standard edition on a Mac. There were two conditions required:
add the additional java param to ignition conf: wrapper.java.additional.2=-Dia.developer.moduleupload=true
First time you install the module, do it via the gateway UI and accept any license terms/certificate
After that, seems that running gradlew deployModl posts to the developer servlet as intended.
Admittedly, I tested using a very simple gateway scoped module, but it was loaded into the gateway as I’d expect.
It looks like it’s trying to force signing the module and erroring out with no certs found, though I am never running the signModule task. Any idea why this is happening?
Then In the new module folder, I ran the build and this is what happened:
kgamble-mbp ➜ ./gradlew build
Starting a Gradle Daemon, 1 busy and 1 incompatible and 1 stopped Daemons could not be reused, use --status for details
Required keystore file location not found. Specify via flag '--keystoreFile=<value>', or in gradle.properties file as 'ignition.signing.keystoreFile=<value>'
Required keystore file location not found. Specify via flag '--keystoreFile=<value>', or in gradle.properties file as 'ignition.signing.keystoreFile=<value>'
Required certificate file location not found. Specify via flag '--certFile=<value>', or in gradle.properties file as 'ignition.signing.certFile=<value>'
Required certificate file location not found. Specify via flag '--certFile=<value>', or in gradle.properties file as 'ignition.signing.certFile=<value>'
> Task :signModule FAILED
Required certificate file location not found. Specify via flag '--certFile=<value>', or in gradle.properties file as 'ignition.signing.certFile=<value>'
Required keystore file location not found. Specify via flag '--keystoreFile=<value>', or in gradle.properties file as 'ignition.signing.keystoreFile=<value>'
Required certificate alias not found. Specify via flag '--certAlias=<value>', or in gradle.properties file as 'ignition.signing.certAlias=<value>'
Required certificate file location not found. Specify via flag '--certFile=<value>', or in gradle.properties file as 'ignition.signing.certFile=<value>'
Required certificate password not found. Specify via flag '--certPassword=<value>', or in gradle.properties file as 'ignition.signing.certPassword=<value>'
Required keystore file location not found. Specify via flag '--keystoreFile=<value>', or in gradle.properties file as 'ignition.signing.keystoreFile=<value>'
Required keystore password not found. Specify via flag '--keystorePassword=<value>', or in gradle.properties file as 'ignition.signing.keystorePassword=<value>'
FAILURE: Build failed with an exception.
* What went wrong:
Some problems were found with the configuration of task ':signModule' (type 'SignModule').
> File '/Users/kgamble/Work/Ignition/Modules/test-module/test/null' specified for property 'certFile' does not exist.
> File '/Users/kgamble/Work/Ignition/Modules/test-module/test/null' specified for property 'keystore' does not exist.
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.
* Get more help at https://help.gradle.org
Deprecated Gradle features were used in this build, making it incompatible with Gradle 7.0.
Use '--warning-mode all' to show the individual deprecation warnings.
See https://docs.gradle.org/6.8.2/userguide/command_line_interface.html#sec:command_line_warnings
BUILD FAILED in 59s
16 actionable tasks: 16 executed
It looks like if I just execute the zipModule task directly it works. However even if I do provide it valid certificates for signing I end up with the following
kgamble-mbp ➜ ./gradlew build
> Task :signModule FAILED
Required certificate password not found. Specify via flag '--certPassword=<value>', or in gradle.properties file as 'ignition.signing.certPassword=<value>'
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':signModule'.
> null cannot be cast to non-null type java.security.interfaces.RSAPrivateKey
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.
* Get more help at https://help.gradle.org
Deprecated Gradle features were used in this build, making it incompatible with Gradle 7.0.
Use '--warning-mode all' to show the individual deprecation warnings.
See https://docs.gradle.org/6.8.2/userguide/command_line_interface.html#sec:command_line_warnings
BUILD FAILED in 1s
16 actionable tasks: 1 executed, 15 up-to-date
This however does not solve the problem of why the build automatically forces a signing. I am trying to dig around and find the answer to that in the plugin, but I am no gradle expert.
This is just a bit of a naive design decision on my part to make signing a fundamental required step in the module assembly process. I figured one would always want a signed module as the end result, but can see how that might be inhibitive for people (especially if you're not familiar with the process of creating/getting a cert to sign with).
We're going to make that more flexible to ease adoption and make routine development/experimentation a bit simpler for folks. Not sure exactly when, but 'soonish' - it'll be part of the next released version of the plugin, and the changes are scheduled to get done in the next couple weeks.
I'd try using fully qualified paths (I personally drop certs in a user home directory). Also think that ignition.signing.certAlias="My Cert Alias" probably shouldn't have quotes. I'd also suggest adding --info or --debug to the gradle execution to get more logging output during cert file resolution.
So separate question, how does one build the generator?