'mvn install', DeveloperModuleLoadingServlet, dependencies

#1

The ‘mvn install’ piece that posts my freshly-compiled module to a running gateway really cuts down on the debug cycle, as you don’t have to kill the gateway and restart (which takes more than a minute on my dev machine).

Unfortunately, when I use this method, the gateway can not find second-order dependencies of my module, I get NoClassDefFoundErrors. (Second-order means a dependency of one of my dependencies.)

When I execute ‘mvn install’, the artifacts that are copied (shown in the build output starting with “copying dependency artifact:”) do not include second-order dependencies. However, ‘mvn package’ does include them.

I’m using Ignition 7.9.1 and ignition-maven-plugin 1.0.9 (I also tried 1.0.12).

Here’s my ignition-maven-plugin config:

            <plugin>
                <groupId>com.inductiveautomation.ignitionsdk</groupId>
                <artifactId>ignition-maven-plugin</artifactId>
                <version>1.0.9</version>

                <executions>
                    <execution>
                        <id>package-modl</id>
                        <phase>package</phase>
                        <goals>
                            <goal>modl</goal>
                        </goals>
                    </execution>
                    <execution>
                        <id>post-module</id>
                        <phase>install</phase>
                        <goals>
                            <goal>modl</goal>
                            <goal>post</goal>
                        </goals>
                    </execution>
                </executions>

                <configuration>
                    <projectScopes>
                        <projectScope>
                            <name>sqim-gateway</name>
                            <scope>G</scope>
                        </projectScope>

                        <projectScope>
                            <name>sqim-designer</name>
                            <scope>D</scope>
                        </projectScope>

                        <projectScope>
                            <name>sqim-client</name>
                            <scope>CD</scope>
                        </projectScope>
                    </projectScopes>

                    <moduleId>com.seeq.ignition</moduleId>
                    <moduleName>Seeq</moduleName>
                    <moduleDescription>Trending, visualizations, calculations, analytics, cleansing, modeling,
                        advanced monitoring and reporting.
                    </moduleDescription>
                    <moduleVersion>${project.version}</moduleVersion>
                    <requiredIgnitionVersion>7.9.0</requiredIgnitionVersion>
                    <requiredFrameworkVersion>7</requiredFrameworkVersion>
                    <!--<licenseFile>license.html</licenseFile>-->
                    <!--<documentationFile>doc/index.html</documentationFile>-->

                    <depends>
                        <depend>
                            <scope>G</scope>
                            <moduleId>xopc</moduleId>
                        </depend>

                        <depend>
                            <scope>D</scope>
                            <moduleId>fpmi</moduleId>
                        </depend>
                    </depends>

                    <hooks>
                        <hook>
                            <scope>G</scope>
                            <hookClass>com.seeq.ignition.gateway.GatewayHook</hookClass>
                        </hook>

                        <hook>
                            <scope>D</scope>
                            <hookClass>com.seeq.ignition.designer.DesignerHook</hookClass>
                        </hook>
                    </hooks>
                </configuration>
            </plugin>
0 Likes

#2

More info:

Adding the “post” goal to the “package” phase causes ‘mvn package’ to post the module to the gateway with the correct dependencies. So it’s a reasonable workaround, but it does mean that you have to manually alter your pom file when you’re iterating in development, and then revert it before committing (since you don’t want the build machine to try to post to a non-existent gateway).

So, it seems there still needs to be a fix made somewhere…

0 Likes

#3

Change the version of ignition-maven-plugin to 1.0.12 and try again. I know we fixed this bug once already, hopefully there hasn’t been a regression.

0 Likes

#4

Hi Kevin, thanks for the response.

I tried 1.0.12 again to be sure-- it still has the problem.

0 Likes

#5

Hey any update on this issue? It’s a bit of a pain to have to remember to modify the POM file when debugging…

0 Likes

#6

I have the same problem

0 Likes

#7

I have resolved adding this parmeter in ignition.conf

wrapper.java.additional.11=-Dia.developer.moduleupload=true

0 Likes

#8

Mau89, I don’t believe it’s the same problem. Adding the parameter you mention allows you to upload (period), but the bug I’m reporting is specific to second-order dependencies being left out during posting when using mvn install.

I’m using the ignition-maven-plugin version 1.0.12 and it still has the problem.

0 Likes

#9

Reviving this topic since it seems there was no resolution, and I am seeing the same behavior in version 1.1.0 of the plugin as described above for versions 1.0.9 and 1.0.12. When using mvn install, only directly-declared dependencies from the gateway project, and the gateway project itself, are included in the module, and none of the transitive dependencies are included. When using mvn package or mvn verify, transitive dependencies are included as expected.

Here’s an example. I have a project that is structured in the same way as one of the example projects:

parent-project   <-- top-level "parent" POM
|-- my-build     <-- "build" POM with ignition-maven-plugin:1.1.0
|-- my-gateway   <-- "gateway" project POM with my source

These are the non-Ignition dependencies declared in my-gateway:

org.apache.kafka:kafka-clients:2.2.0
com.fasterxml.jackson.core:jackson-databind:2.9.9
com.fasterxml.jackson.datatype:jackson-datatype-jsr310:2.9.9

Running Maven on parent-project results in building my-gateway and then my-build as expected. However, when ignition-maven-plugin is invoked in my-build, it has different behavior depending on the Maven phase requested.

parent-project $ mvn clean install

...
[INFO] copying g artifacts
[INFO] copying dependency artifact: jackson-datatype-jsr310-2.9.9.jar
[INFO] copying dependency artifact: my-gateway-1.2.0.jar
[INFO] copying dependency artifact: jackson-databind-2.9.9.jar
[INFO] copying dependency artifact: kafka-clients-2.2.0.jar
...

Using install, only the dependencies directly declared in the POM of my gateway project, and the gateway project itself, were included.

parent-project $ mvn clean package
or
parent-project $ mvn clean verify

...
INFO] copying g artifacts
[INFO] copying dependency artifact: slf4j-api-1.7.25.jar
[INFO] copying dependency artifact: jackson-datatype-jsr310-2.9.9.jar
[INFO] copying dependency artifact: lz4-java-1.5.0.jar
[INFO] copying dependency artifact: jackson-core-2.9.9.jar
[INFO] copying dependency artifact: my-gateway-1.2.0.jar
[INFO] copying dependency artifact: zstd-jni-1.3.8-1.jar
[INFO] copying dependency artifact: jackson-databind-2.9.9.jar
[INFO] copying dependency artifact: jackson-annotations-2.9.0.jar
[INFO] copying dependency artifact: kafka-clients-2.2.0.jar
[INFO] copying dependency artifact: snappy-java-1.1.7.2.jar

Using package or verify, the declared dependencies and their transitive dependencies have been included, as well as the gateway project itself.

Without the transitive dependencies, the module of course does not work. Looks like there could be a regression if this behavior has been fixed before.

0 Likes

#10

FWIW I am also still experiencing the same problem with the latest version of the Maven plugin.

0 Likes

#11

This hasn’t really been high enough priority to ever dig into. We looked at it real quick a long time ago and got nowhere.

I’ve been meaning to open source ignition-maven-plugin for a while now… I’ll try to get around to it and then if this issue is really important to you then you can try to fix it yourself :slight_smile:

0 Likes

#12

That sounds good to me. Maven always was kind of a mysterious black box type of thing to me, making it hard to figure out what’s going on when something goes wrong. Having a closed-source plugin inside of it is like nested black boxes. :slight_smile:

If this could be made part of the SDK, I’d dig in and try to fix the problem so as to save the next person the hours of head-scratching that I went through. Thanks for working to open it up!

0 Likes

#13

Et voila: https://github.com/inductiveautomation/ignition-maven-plugin

1 Like

#14

Thanks, that’s great! I’ll take a look at it this week and see if I can spot the transitive dependencies issue (assuming someone else doesn’t find it first!).

0 Likes