With "system" scope, the container is expected to provide the artefact. From the maven docs:
provided
This is much like compile, but indicates you expect the JDK or a
container to provide the dependency at
runtime. For example, when building a
web application for the Java
Enterprise Edition, you would set the
dependency on the Servlet API and
related Java EE APIs to scope provided
because the web container provides
those classes. This scope is only
available on the compilation and test
classpath, and is not transitive.
[...]
system
This scope is similar to provided except that you have to
provide the JAR which contains it
explicitly. The artifact is always
available and is not looked up in a
repository.
By using a system scope, you are indicating to the war plugin that the container will provide this dependency. Since this is not what you are intending to do, the simplest solution is to put the artefact in a repository, either your local maven repository, or your own maven repo on your intranet, if you have one.
The install:install-file goal can be used to install a single file (without POM) to your local repository. After doing this, change the dependency type to "compile" and remove the "systemPath" element.
In my day job, we use Nexus to manage a company-wide repository on our intranet. You can have separate repositories for your own artefacts, vs third party artefacts. Nexus also acts as a proxy, caching artefacts from external repositories, speeding up the build quite a bit. This means that only the developer that uses a new dependency that is not available in the other repos has to upload - after that, all the other devs can use it - they can checkout from SCM and build without worrying about where the dependencies are located.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…