JZMQ with Tomcat 8.0 keeps throwing NoClassDefFoundError

I have a webapp project that uses maven.

In the project's pom.xml file, there's a dependency element referring to the JZMQ jar file which resides in the local filesystem, like this:

    <dependency>
        <groupId>com.external.jzmq</groupId>
        <artifactId>zmq</artifactId>
        <version>3.1.0</version>
        <scope>system</scope>
        <systemPath>${external.lib.path}</systemPath>
    </dependency>

with external.lib.path being the filepath in the local filesystem.

This JZMQ jar file is built from libzmq v4.1.6, and JZMQ v3.1.0, if that helps.

This project is then loaded in Eclipse (x86_x64 Windows, 2023-06) and is supposed to run on a Tomcat v7.0 server. The thing is, when I try to load and run the project on Tomcat, it always throws this:

java.lang.NoClassDefFoundError: org/zeromq/ZContext
    at hub.wgw.AgentSingleton.<init>(AgentSingleton.java:45)
    at hub.wgw.AgentSingleton.<clinit>(AgentSingleton.java:26)
    at launch.TomcatStartup.contextInitialized(TomcatStartup.java:14)
    at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:5128)
    at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5653)
    at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
    at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1689)
    at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1679)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
    at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.ClassNotFoundException: org.zeromq.ZContext
    at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1951)
    at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1795)
    ... 12 more

(with hub.wgw.AgentSingleton being a class from this project)

I should also state that JZMQ is the only option here. I cannot use JeroMQ or JCZMQ for some compatibility reasons. Similarly, getting JZMQ from the Maven Repo is out of the option as well.

I am almost absolutely sure that this is not a fault in the JZMQ's side, for I already have tried using the exact same jar file in a simpler maven project to make sure it correctly runs, using the snippets from here: No jzmq in java.library.path

More precisely, I have created 2 different, smaller sized Maven projects that ping-pongs back and forth using JZMQ, and booted up both. It gave me the expected result, without any errors or whatnot.

I would like to know the reason why this keeps happening when I can use it with no problem with other projects, and if possible, a way to fix it.

Edit: I can solve the problem easily enough by simply copy-pasting the jar file in question inside Tomcat's lib directory, but that defeats the purpose of using Maven in the first place. I would like an explanation, rather than a workaround. Thanks in advance.

Solution

Solved! It looks like I was looking at the wrong place.

If a dependency has system as its' scope, then the dependency in question is omitted in the final build. This was why it kept throwing errors despite the build being successful.

The reason why it worked fine with my test projects was that it managed to grab and use the jzmq jar file right away, since it ran on a standalone project, contrary to this current project which runs on Tomcat.

So, the key was to remove the scope and systemPath attributes, then add something like below:

<repositories>
    <repository>
        <id>com-external-jzmq</id>
        <url>file://[local repository location]</url>
    </repository>
</repositories>

This sets up a local repository, which can then be used to find jar files within. Then, it's a matter of placing the jzmq jar file such that (some path)\com.external.jzmq\zmq\3.1.0\zmq-3.1.0.jar is a valid path.

From what I understand, this path should match the dependency's group ID, artifact ID and version. i.e. (group ID)\(artifact ID)\(version) should be the path.