Develop Reference

Maven is not adding a library to the final JAR [duplicate]

I have a proprietary jar that I want to add to my pom as a dependency.
But I don't want to add it to a repository. The reason is that I want my usual maven commands such as mvn compile, etc, to work out of the box. (Without demanding from the developers a to add it to some repository by themselves).
I want the jar to be in a 3rdparty lib in source control, and link to it by relative path from the pom.xml file.
Can this be done? How?

I want the jar to be in a 3rdparty lib in source control, and link to it by relative path from the pom.xml file.
If you really want this (understand, if you can't use a corporate repository), then my advice would be to use a "file repository" local to the project and to not use a system scoped dependency. The system scoped should be avoided, such dependencies don't work well in many situation (e.g. in assembly), they cause more troubles than benefits.
So, instead, declare a repository local to the project:
<repositories>
<repository>
<id>my-local-repo</id>
<url>file://${project.basedir}/my-repo</url>
</repository>
</repositories>
Install your third party lib in there using install:install-file with the localRepositoryPath parameter:
mvn install:install-file -Dfile=<path-to-file> -DgroupId=<myGroup> \
-DartifactId=<myArtifactId> -Dversion=<myVersion> \
-Dpackaging=<myPackaging> -DlocalRepositoryPath=<path>
Update: It appears that install:install-file ignores the localRepositoryPath when using the version 2.2 of the plugin. However, it works with version 2.3 and later of the plugin. So use the fully qualified name of the plugin to specify the version:
mvn org.apache.maven.plugins:maven-install-plugin:2.3.1:install-file \
-Dfile=<path-to-file> -DgroupId=<myGroup> \
-DartifactId=<myArtifactId> -Dversion=<myVersion> \
-Dpackaging=<myPackaging> -DlocalRepositoryPath=<path>
maven-install-plugin documentation
Finally, declare it like any other dependency (but without the system scope):
<dependency>
<groupId>your.group.id</groupId>
<artifactId>3rdparty</artifactId>
<version>X.Y.Z</version>
</dependency>
This is IMHO a better solution than using a system scope as your dependency will be treated like a good citizen (e.g. it will be included in an assembly and so on).
Now, I have to mention that the "right way" to deal with this situation in a corporate environment (maybe not the case here) would be to use a corporate repository.

Using the system scope. ${basedir} is the directory of your pom.
<dependency>
<artifactId>..</artifactId>
<groupId>..</groupId>
<scope>system</scope>
<systemPath>${basedir}/lib/dependency.jar</systemPath>
</dependency>
However it is advisable that you install your jar in the repository, and not commit it to the SCM - after all that's what maven tries to eliminate.

This is another method in addition to my previous answer at Can I add jars to maven 2 build classpath without installing them?
This will get around the limit when using multi-module builds especially if the downloaded JAR is referenced in child projects outside of the parent. This also reduces the setup work by creating the POM and the SHA1 files as part of the build. It also allows the file to reside anywhere in the project without fixing the names or following the maven repository structure.
This uses the maven-install-plugin. For this to work, you need to set up a multi-module project and have a new project representing the build to install files into the local repository and ensure that one is first.
You multi-module project pom.xml would look like this:
<packaging>pom</packaging>
<modules>
<!-- The repository module must be first in order to ensure
that the local repository is populated -->
<module>repository</module>
<module>... other modules ...</module>
</modules>
The repository/pom.xml file will then contain the definitions to load up the JARs that are part of your project. The following are some snippets of the pom.xml file.
<artifactId>repository</artifactId>
<packaging>pom</packaging>
The pom packaging prevents this from doing any tests or compile or generating any jar file. The meat of the pom.xml is in the build section where the maven-install-plugin is used.
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-install-plugin</artifactId>
<executions>
<execution>
<id>com.ibm.db2:db2jcc</id>
<phase>verify</phase>
<goals>
<goal>install-file</goal>
</goals>
<configuration>
<groupId>com.ibm.db2</groupId>
<artifactId>db2jcc</artifactId>
<version>9.0.0</version>
<packaging>jar</packaging>
<file>${basedir}/src/jars/db2jcc.jar</file>
<createChecksum>true</createChecksum>
<generatePom>true</generatePom>
</configuration>
</execution>
<execution>...</execution>
</executions>
</plugin>
</plugins>
</build>
To install more than one file, just add more executions.

This is working for me:
Let's say I have this dependency
<dependency>
<groupId>com.company.app</groupId>
<artifactId>my-library</artifactId>
<version>1.0</version>
<scope>system</scope>
<systemPath>${project.basedir}/lib/my-library.jar</systemPath>
</dependency>
Then, add the class-path for your system dependency manually like this
<Class-Path>libs/my-library-1.0.jar</Class-Path>
Full config:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>2.4</version>
<configuration>
<archive>
<manifestEntries>
<Build-Jdk>${jdk.version}</Build-Jdk>
<Implementation-Title>${project.name}</Implementation-Title>
<Implementation-Version>${project.version}</Implementation-Version>
<Specification-Title>${project.name} Library</Specification-Title>
<Specification-Version>${project.version}</Specification-Version>
<Class-Path>libs/my-library-1.0.jar</Class-Path>
</manifestEntries>
<manifest>
<addClasspath>true</addClasspath>
<mainClass>com.company.app.MainClass</mainClass>
<classpathPrefix>libs/</classpathPrefix>
</manifest>
</archive>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.5.1</version>
<executions>
<execution>
<id>copy-dependencies</id>
<phase>package</phase>
<goals>
<goal>copy-dependencies</goal>
</goals>
<configuration>
<outputDirectory>${project.build.directory}/libs/</outputDirectory>
</configuration>
</execution>
</executions>
</plugin>

Basically, add this to the pom.xml:
...
<repositories>
<repository>
<id>lib_id</id>
<url>file://${project.basedir}/lib</url>
</repository>
</repositories>
...
<dependencies>
...
<dependency>
<groupId>com.mylibrary</groupId>
<artifactId>mylibraryname</artifactId>
<version>1.0.0</version>
</dependency>
...
</dependencies>

I've previously written about a pattern for doing this.
It is very similar to the solution proposed by Pascal, though it moves all such dependencies into a dedicated repository module so that you don't have to repeat it everywhere the dependency is used if it is a multi-module build.

we switched to gradle and this works much better in gradle ;). we just specify a folder we can drop jars into for temporary situations like that. We still have most of our jars defined i the typicaly dependency management section(ie. the same as maven). This is just one more dependency we define.
so basically now we can just drop any jar we want into our lib dir for temporary testing if it is not a in maven repository somewhere.

One small addition to the solution posted by Pascal
When I followed this route, I got an error in maven while installing ojdbc jar.
[INFO] --- maven-install-plugin:2.5.1:install-file (default-cli) # validator ---
[INFO] pom.xml not found in ojdbc14.jar
After adding -DpomFile, the problem was resolved.
$ mvn install:install-file -Dfile=./lib/ojdbc14.jar -DgroupId=ojdbc \
-DartifactId=ojdbc -Dversion=14 -Dpackaging=jar -DlocalRepositoryPath=./repo \
-DpomFile=~/.m2/repository/ojdbc/ojdbc/14/ojdbc-14.pom

I was facing with the same issue, and it works just removing the DlocalRepositoryPath parameter and defining the correct path from current location in the Dfile parameter:
mvn install:install-file -Dfile=./repo/com/tridion/cd_core/1.0/cd_core-1.0.jar -DgroupId=com.tridion -DartifactId=cd_core -Dversion=1.0 -Dpackaging=jar
Note: Apache Maven 3.8.6

You can use eclipse to generate a runnable Jar :
Export/Runable Jar file

how to deploy multiple wars using the tomcat plugin in maven

From the forums that I followed I tried some ways to find a way to deploy mutliple wars using tomcat plugin in maven but I could not succeed.
I created a third project and used three projects in order to deploy them but I have not done it. Could you please tell me way to do it ?
Best Regards
Alper Kopuz
Here is the pom.xml that I used :
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>
tr.com.provus.pays
</groupId>
<artifactId>PAYSGroupProject</artifactId>
<version>1.0</version>
<packaging>pom</packaging>
<modules>
<module>../PAYSWeb</module>
<module>../PAYSDashboard</module>
<module>../PAYSStaticWeb</module>
</modules>
<name>PAYSGroupProject</name>
<url>http://maven.apache.org</url>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>
<build>
<plugins>
<plugin>
<groupId>org.apache.tomcat.maven</groupId>
<artifactId>tomcat7-maven-plugin</artifactId>
<executions>
<execution>
<id>deploy</id>
<phase>pre-integration-test</phase>
<goals>
<goal>run</goal>
</goals>
</execution>
</executions>
<configuration>
<warSourceDirectory>WebContent</warSourceDirectory>
</configuration>
</plugin>
</plugins>
</build>
</project>

I guess you cannot use the tomcat plugin on a pom type project, try instead to configure the plugin into one of the war projects and include the others as webapp dependencies with something like that :
<configuration>
<webapps>
<webapp>
<contextPath>/PAYSWeb</contextPath>
<groupId>tr.com.provus.pays</groupId>
<artifactId>PAYSWeb</artifactId>
<version>${project.version}</version>
<type>war</type>
<asWebapp>true</asWebapp>
</webapp>
<webapp>...</webapp>
</webapps>
</configuration>
Look also at this post (but unanswered)

Each webapp will need a different context root which is supplied to the tomcat7 maven plugin with the "path" value.
You will deploy each web app from its own POM independently. But since you have a pom type project that causes the others to build, you should be able to redeploy all three at once.
Note that there are two ways to deploy using this plugin:
You can deploy without the war. It just compiles the java files and deploys them directly to tomcat.
You can deploy the war. Maven will have to build the war and then it gets deployed to Tomcat. This is more like a production deployment and helps you verify the war will deploy correctly.
So. Move your plugin XML to each of the three "modules" pom files. They will have type 'war'. Then add this under configuration:
<path>paysWeb</path>
under the <configuration> tag for the first 'module'. Of course, you use the different names for the <path> for each of the 'module's.
There is more info here: http://tomcat.apache.org/maven-plugin-2.0/tomcat7-maven-plugin/usage.html

How to set up a minimal Maven pom.xml file for a Heroku worker process in Java?

First off: I'm not a Java coder. I'm new to the Java/Maven tool chain. We're using a Java library for a project which we want to launch as a Heroku background worker.
This project relies on two external libraries, the mongodb Java driver which is available through Maven's central repo, and another third party library. I've seen the Heroku article on "unmanaged dependencies", but something else appears missing, as I get an error like: Could not find the main class: com.company.myproject.MyApp Program will exit. when I try to run the app locally according to Heroku's instructions on "Getting Started with Java".
I noticed that their pom.xml file contains a Maven plugin maven-dependency-plugin to copy dependencies, and when I check my target/classes folder, I don't see any of the dependencies.
Heroku also publishes a guide on building background workers in Java. That pom.xml contains a build assembly plugin, which seems more complex.
I'm a bit lost in all this ceremony (especially coming from Rails), and I'd like to stat with the simplest possible pom.xml to get this running. Is there a Maven archetype file for Java workers on Heroku? I'm also using NetBeans as IDE, and it would be great to use the IDE tools for this, if available, but it's a secondary priority.
Below my pom.xml so far:
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.myproject</groupId>
<artifactId>myproject</artifactId>
<version>0.1</version>
<packaging>jar</packaging>
<name>myproject</name>
<url>http://maven.apache.org</url>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.mongodb</groupId>
<artifactId>mongo-java-driver</artifactId>
<version>2.7.3</version>
</dependency>
<dependency>
<groupId>org.thirdparty</groupId>
<artifactId>thirdparty</artifactId>
<version>0.2.9</version>
<scope>provided</scope>
</dependency>
</dependencies>
<repositories>
<repository>
<id>project-local</id>
<name>Project-local Repo</name>
<url>file:${project.basedir}/repo</url>
</repository>
</repositories>
</project>

You definitely need to use the maven-dependency-plugin to copy all of the dependencies into the target/dependency directory:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.4</version>
<executions>
<execution>
<id>copy-dependencies</id>
<phase>package</phase>
<goals><goal>copy-dependencies</goal></goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
Then your Procfile needs to include those dependencies in the classpath:
foo: java -cp target/classes:target/dependency/* com.myproject.Main
Where com.myproject.Main is the class name of the Java class you want to run (which must contain a public static void main method. Note that this also adds the Java classes which are compiled from src/main/java into the target/classes dir.

Maven: add a dependency to a jar by relative path

I have a proprietary jar that I want to add to my pom as a dependency.
But I don't want to add it to a repository. The reason is that I want my usual maven commands such as mvn compile, etc, to work out of the box. (Without demanding from the developers a to add it to some repository by themselves).
I want the jar to be in a 3rdparty lib in source control, and link to it by relative path from the pom.xml file.
Can this be done? How?

I want the jar to be in a 3rdparty lib in source control, and link to it by relative path from the pom.xml file.
If you really want this (understand, if you can't use a corporate repository), then my advice would be to use a "file repository" local to the project and to not use a system scoped dependency. The system scoped should be avoided, such dependencies don't work well in many situation (e.g. in assembly), they cause more troubles than benefits.
So, instead, declare a repository local to the project:
<repositories>
<repository>
<id>my-local-repo</id>
<url>file://${project.basedir}/my-repo</url>
</repository>
</repositories>
Install your third party lib in there using install:install-file with the localRepositoryPath parameter:
mvn install:install-file -Dfile=<path-to-file> -DgroupId=<myGroup> \
-DartifactId=<myArtifactId> -Dversion=<myVersion> \
-Dpackaging=<myPackaging> -DlocalRepositoryPath=<path>
Update: It appears that install:install-file ignores the localRepositoryPath when using the version 2.2 of the plugin. However, it works with version 2.3 and later of the plugin. So use the fully qualified name of the plugin to specify the version:
mvn org.apache.maven.plugins:maven-install-plugin:2.3.1:install-file \
-Dfile=<path-to-file> -DgroupId=<myGroup> \
-DartifactId=<myArtifactId> -Dversion=<myVersion> \
-Dpackaging=<myPackaging> -DlocalRepositoryPath=<path>
maven-install-plugin documentation
Finally, declare it like any other dependency (but without the system scope):
<dependency>
<groupId>your.group.id</groupId>
<artifactId>3rdparty</artifactId>
<version>X.Y.Z</version>
</dependency>
This is IMHO a better solution than using a system scope as your dependency will be treated like a good citizen (e.g. it will be included in an assembly and so on).
Now, I have to mention that the "right way" to deal with this situation in a corporate environment (maybe not the case here) would be to use a corporate repository.

Using the system scope. ${basedir} is the directory of your pom.
<dependency>
<artifactId>..</artifactId>
<groupId>..</groupId>
<scope>system</scope>
<systemPath>${basedir}/lib/dependency.jar</systemPath>
</dependency>
However it is advisable that you install your jar in the repository, and not commit it to the SCM - after all that's what maven tries to eliminate.

This is another method in addition to my previous answer at Can I add jars to maven 2 build classpath without installing them?
This will get around the limit when using multi-module builds especially if the downloaded JAR is referenced in child projects outside of the parent. This also reduces the setup work by creating the POM and the SHA1 files as part of the build. It also allows the file to reside anywhere in the project without fixing the names or following the maven repository structure.
This uses the maven-install-plugin. For this to work, you need to set up a multi-module project and have a new project representing the build to install files into the local repository and ensure that one is first.
You multi-module project pom.xml would look like this:
<packaging>pom</packaging>
<modules>
<!-- The repository module must be first in order to ensure
that the local repository is populated -->
<module>repository</module>
<module>... other modules ...</module>
</modules>
The repository/pom.xml file will then contain the definitions to load up the JARs that are part of your project. The following are some snippets of the pom.xml file.
<artifactId>repository</artifactId>
<packaging>pom</packaging>
The pom packaging prevents this from doing any tests or compile or generating any jar file. The meat of the pom.xml is in the build section where the maven-install-plugin is used.
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-install-plugin</artifactId>
<executions>
<execution>
<id>com.ibm.db2:db2jcc</id>
<phase>verify</phase>
<goals>
<goal>install-file</goal>
</goals>
<configuration>
<groupId>com.ibm.db2</groupId>
<artifactId>db2jcc</artifactId>
<version>9.0.0</version>
<packaging>jar</packaging>
<file>${basedir}/src/jars/db2jcc.jar</file>
<createChecksum>true</createChecksum>
<generatePom>true</generatePom>
</configuration>
</execution>
<execution>...</execution>
</executions>
</plugin>
</plugins>
</build>
To install more than one file, just add more executions.

This is working for me:
Let's say I have this dependency
<dependency>
<groupId>com.company.app</groupId>
<artifactId>my-library</artifactId>
<version>1.0</version>
<scope>system</scope>
<systemPath>${project.basedir}/lib/my-library.jar</systemPath>
</dependency>
Then, add the class-path for your system dependency manually like this
<Class-Path>libs/my-library-1.0.jar</Class-Path>
Full config:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>2.4</version>
<configuration>
<archive>
<manifestEntries>
<Build-Jdk>${jdk.version}</Build-Jdk>
<Implementation-Title>${project.name}</Implementation-Title>
<Implementation-Version>${project.version}</Implementation-Version>
<Specification-Title>${project.name} Library</Specification-Title>
<Specification-Version>${project.version}</Specification-Version>
<Class-Path>libs/my-library-1.0.jar</Class-Path>
</manifestEntries>
<manifest>
<addClasspath>true</addClasspath>
<mainClass>com.company.app.MainClass</mainClass>
<classpathPrefix>libs/</classpathPrefix>
</manifest>
</archive>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.5.1</version>
<executions>
<execution>
<id>copy-dependencies</id>
<phase>package</phase>
<goals>
<goal>copy-dependencies</goal>
</goals>
<configuration>
<outputDirectory>${project.build.directory}/libs/</outputDirectory>
</configuration>
</execution>
</executions>
</plugin>

Basically, add this to the pom.xml:
...
<repositories>
<repository>
<id>lib_id</id>
<url>file://${project.basedir}/lib</url>
</repository>
</repositories>
...
<dependencies>
...
<dependency>
<groupId>com.mylibrary</groupId>
<artifactId>mylibraryname</artifactId>
<version>1.0.0</version>
</dependency>
...
</dependencies>

I've previously written about a pattern for doing this.
It is very similar to the solution proposed by Pascal, though it moves all such dependencies into a dedicated repository module so that you don't have to repeat it everywhere the dependency is used if it is a multi-module build.

we switched to gradle and this works much better in gradle ;). we just specify a folder we can drop jars into for temporary situations like that. We still have most of our jars defined i the typicaly dependency management section(ie. the same as maven). This is just one more dependency we define.
so basically now we can just drop any jar we want into our lib dir for temporary testing if it is not a in maven repository somewhere.

One small addition to the solution posted by Pascal
When I followed this route, I got an error in maven while installing ojdbc jar.
[INFO] --- maven-install-plugin:2.5.1:install-file (default-cli) # validator ---
[INFO] pom.xml not found in ojdbc14.jar
After adding -DpomFile, the problem was resolved.
$ mvn install:install-file -Dfile=./lib/ojdbc14.jar -DgroupId=ojdbc \
-DartifactId=ojdbc -Dversion=14 -Dpackaging=jar -DlocalRepositoryPath=./repo \
-DpomFile=~/.m2/repository/ojdbc/ojdbc/14/ojdbc-14.pom

I was facing with the same issue, and it works just removing the DlocalRepositoryPath parameter and defining the correct path from current location in the Dfile parameter:
mvn install:install-file -Dfile=./repo/com/tridion/cd_core/1.0/cd_core-1.0.jar -DgroupId=com.tridion -DartifactId=cd_core -Dversion=1.0 -Dpackaging=jar
Note: Apache Maven 3.8.6

You can use eclipse to generate a runnable Jar :
Export/Runable Jar file

Maven: avoid deploying project package-implied artifact during standard build lifecycle

Is it possible to avoid deploying the artifact that is built according to the project packaging during 'deploy:deploy' processing?
I mean the following:
suppose we have a 'pom.xml' for web application and define packaging type as 'war';
we want to assemble either '*.war' artifact or '*.zip' that contains our application as well as a servlet container;
we want to deploy only that '*.zip' artifact during 'deploy:deploy' processing;
I.e. I want to be able to run 'mvn deploy' and has the following results:
'myapp.war' is constructed;
'myapp-standalone.zip' is constructed;
'myapp-standalone.zip' is deployed to the target remote repository (note that I don't bother if 'myapp.war' is installed to the local repository here);
I checked 'war:war documentation' and found 'primaryArtifact' parameter. However, it mentions only local repository.
I tried the following POM but it still deploys either '*.war' or '*.zip' to remote repository:
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.mygroup</groupId>
<artifactId>myapp</artifactId>
<packaging>war</packaging>
<version>1.0-SNAPSHOT</version>
<name>myapp</name>
<url>http://maven.apache.org</url>
<dependencies>
<!-- dependencies go here -->
</dependencies>
<build>
<plugins>
<! -- plugins like 'compiler' etc -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<configuration>
<primaryArtifact>false</primaryArtifact>
</configuration>
</plugin>
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<executions>
<execution>
<id>myapp-standalone</id>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
<configuration>
<descriptors>
<descriptor>src/main/assembly/standalone.xml</descriptor>
</descriptors>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
<distributionManagement>
<repository>
<-- target repository information -->
</repository>
<snapshotRepository>
<-- target repository information -->
</snapshotRepository>
</distributionManagement>
</project>
It seems that I can get desired behavior via declaring project packaging as 'pom' and manually configuring all mojos implied by 'war' packaging ('resources:resources', 'compiler:compile', 'resources:testResources', 'compiler:testCompile', 'surefire:test', 'war:war', 'install:install', 'deploy:deploy'). However, that would make the POM rather verbose and I'd like to avoid that.
As far as I understand, Maven way is to always have an artifact implied by project packaging type as a one of project artifacts. But it's not clear what Maven user is expected to do if he or she wants to get an artifact that is not matched to any default packing types (e.g. single '*.zip' archive).
Any thoughts?
Regards, Denis

According to the Maven Deploy Plugin documentation:
deploy:deploy is used to automatically install the artifact, its pom and the attached artifacts produced by a particular project. [...]
So I don't think it's possible to prevent your war from being deployed "as is".
However, to obtain the desired effect, you could add a specific module to your build that would be in charge of producing the assembly (the assembly would depend on the war module) and configure the deploy plugin in the war module to skip deployment as follows:
<plugin>
<artifactId>maven-deploy-plugin</artifactId>
<version>X.Y</version>
<configuration>
<skip>true</skip>
</configuration>
</plugin>