Develop Reference

Spring Boot Maven Plugin - No BOOT-INF directory

Between version 1.3.8.RELEASE of the spring-boot-maven-plugin and version 1.4.0.RELEASE - there has been a change in the generated package structure (if you extract the uber jar file)
1.3.8.RELEASE com, lib, META-INF and org directories
1.4.0.RELEASE has a BOOT-INF, META-INF and org directories
Basically from 1.4.0.RELEASE onwards - all the classes and libs are in the BOOT-INF directory.
Due to this - when you try to run a Spring Boot project on Amazon Lambda - it says that there is a jar not found as it cannot read the new Spring Boot Uber jar structure
My question is - is it possible in the newer versions of the Spring Boot Maven Plugin to get it to generate the uber jar to be the same structure as in version 1.3.9.RELEASE?
I tried the maven-shade-plugin - but that leads to other issues
Any help is greatly appreciated
Thanks
Damien

The solution was to add the MODULE layout for the plugin in the pom.xml file
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<configuration>
<layout>MODULE</layout>
</configuration>
<executions>
<execution>
<goals>
<goal>repackage</goal>
</goals>
</execution>
</executions>
</plugin>

In my case I'm using spring boot 2.X and I declared the spring-boot-maven-plugin after the maven-dependency-plugin (which I used to unpack and create exploded app in Docker) and it must be before the unpack, makes sense, it was unpacking before the spring boot maven plugin executed. Next time I'll declare it first thing in the plugin chain, lost more than 1 hour on this. Hope it helps someone.
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<configuration>
<mainClass>${spring.boot.mainClass}</mainClass>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<id>unpack</id>
<phase>package</phase>
<goals>
<goal>unpack</goal>
</goals>
<configuration>
<artifactItems>
<artifactItem>
<groupId>${project.groupId}</groupId>
<artifactId>${project.artifactId}</artifactId>
<version>${project.version}</version>
</artifactItem>
</artifactItems>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>

The answer above with
<layout>MODULE</layout>
does not work anymore, this is because layout element is deprecated in Spring Boot 2.x.
I am using Spring Boot 2.0.x, I found this helpful comment on github:
Support for the module layout was removed in Spring Boot 2.0 having been deprecated in 1.5. Unfortunately, the updates to the Maven Plugin's documentation were missed so we can use this issue to sort that out. You should use a custom LayoutFactory instead.
But as I did not want to implement LayoutFactory I tried this second solution below that actually repackage and creates an extra jar with a classifier given name:
This is due to the change in layout of executable jars in Spring Boot 1.4. Application classes are now packaging in BOOT-INF/classes.
Your client module depends on the repackaged, fat jar of your web module. Due to the new layout that means that the client module can no longer load the web module's classes. If you want to use your web module as a dependency, you should configure Boot's repackaging to apply a classifier to the fat jar. For example:
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<executions>
<execution>
<goals>
<goal>repackage</goal>
</goals>
<configuration>
<classifier>exec</classifier>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
Doing so will allow other modules to depend on the original jar that does not embed the module's dependencies and has the classes at the root of the jar.
One original jar have the same structure as I wanted like
com.my-package.foo.bar
META-INF
and the second classifier have the newer structure with BOOT-INF/ etc.

For me, the solution was a bit more insidious....I had the spring-boot-maven-plugin nested under pluginManagement, (see below). Doh!
The nasty thing, is that when I'd run mvn spring-boot:run, spring boot comes up just fine, and runs app! It wasn't until we tried to deploy to PCF (as a spring-boot JAR), that we'd get an error that there was something wrong with format of the binary....
<build>
<!--
DON'T DO THIS!!
-->
<pluginManagement>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<version>${spring.boot.version}</version>
<executions>
<execution>
<goals>
<goal>repackage</goal>
<goal>build-info</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</pluginManagement>
<!--
DO THIS INSTEAD!!
-->
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<version>${spring.boot.version}</version>
<executions>
<execution>
<goals>
<goal>repackage</goal>
<goal>build-info</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
Once I removed the pluginManagement tags from the POM, I would now get the ./BOOT-INF structure. Please keep in mind that pluginManagement is typically for a parent-pom structure, where you want that plugin's config used across other modules.

I was using Gradle, instead of Maven, and this is what I had to do:
1- In my build.gradle, I added the following properties as defined in https://spring.io/guides/gs/spring-boot-Docker/.
buildscript {
...
dependencies {
...
classpath('gradle.plugin.com.palantir.gradle.docker:gradle-docker:0.13.0')
}
}
group = 'springio'
...
apply plugin: 'com.palantir.docker'
task unpack(type: Copy) {
dependsOn bootJar
from(zipTree(tasks.bootJar.outputs.files.singleFile))
into("build/dependency")
}
docker {
name "${project.group}/${bootJar.baseName}"
copySpec.from(tasks.unpack.outputs).into("dependency")
buildArgs(['DEPENDENCY': "dependency"])
}
2- My dependency folder was not being written to
ARG DEPENDENCY=target/dependency
instead, I located it in another folder, so I changed this property in the Dockerfile:
ARG DEPENDENCY=build/dependency
With this I got a successful build.

Include git commit hash in jar version

I'm using maven and my goal is to include the git commit hash in the version number. Something like : 1.1.{git_hash}.
I'm trying to follow this tutorial.
Q: is it possible to somehow override the version number specified in the version element of the pom file?

One way to achieve this is to use the git-commit-id-plugin. Add this to the list of plugins in the build section of your pom.xml:
<plugin>
<groupId>pl.project13.maven</groupId>
<artifactId>git-commit-id-plugin</artifactId>
<version>${git-commit-id-plugin.version}</version>
<executions>
<execution>
<id>get-the-git-infos</id>
<goals>
<goal>revision</goal>
</goals>
<phase>validate</phase>
</execution>
</executions>
<configuration>
<dotGitDirectory>${project.basedir}/.git</dotGitDirectory>
</configuration>
</plugin>
Note, that I've changed the phase to validate, so the revision number property is already available in when the artifact is packaged.
Then, add the following to the build section:
<build>
<finalName>${project.artifactId}-${project.version}-${git.commit.id.describe-short}</finalName>
<!-- your list of plugins -->
</build>
The git.commit.id.describe-short property is produced by the git-commit-id-plugin. It contains current git revision number (shortened to 7 digits) and an optional dirty indicator.
The produced artifact will look like this: examplelib-1.0.2-efae3b9.jar (or examplelib-1.0.2-efae3b9-dirty.jar in case there are uncommitted changes on your repository).
Additionally, you might also want to put this information to the MANIFEST.MF of your artifact. In such case add this to your list of plugins (the example assumes the artifact is a jar):
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<configuration>
<archive>
<manifestEntries>
<SCM-Revision>${git.commit.id.describe-short}</SCM-Revision>
</manifestEntries>
</archive>
</configuration>
</plugin>
Additional remarks:
I've shown a simple configuration of the git-commit-id-plugin. On their site you may find more options and properties. In addition to properties, that can be used inside pom.xml, the plugin can also generate a properties file containing information about revision.
As an alternative to git-commit-id-plugin, you might prefer buildnumber-maven-plugin. In order to get revision numbers this plugin requires a SCM plugin also configured in your pom.xml.
This setup may interfere with other plugins that transform or rename your artifacts (in my case it was the maven-shade-plugin - one of the sources jar it produces did not contain proper revision number).

The above accepted answer didn't work for me. I found the link https://dzone.com/articles/maven-git-commit-id-plugin, from where I copied the plugin code below. It worked first time for me. I now have the git.properties file automatically included in my target JAR file. Very useful for tracking.
<plugin>
<groupId>pl.project13.maven</groupId>
<artifactId>git-commit-id-plugin</artifactId>
<version>2.2.4</version>
<executions>
<execution>
<id>get-the-git-infos</id>
<goals>
<goal>revision</goal>
</goals>
</execution>
</executions>
<configuration>
<dotGitDirectory>${project.basedir}/.git</dotGitDirectory>
<prefix>git</prefix>
<verbose>false</verbose>
<generateGitPropertiesFile>true</generateGitPropertiesFile>
<generateGitPropertiesFilename>${project.build.outputDirectory}/git.properties</generateGitPropertiesFilename>
<format>json</format>
<gitDescribe>
<skip>false</skip>
<always>false</always>
<dirty>-dirty</dirty>
</gitDescribe>
</configuration>
Add finalName to build section to also have the version in the target file name
<build>
<finalName>${project.artifactId}-${project.version}-${git.commit.id.describe-short}</finalName>
...
</build>

How to set different version for all child in a multi module maven project setup

We have multi module project setup with a lot of dependencies on different modules versions.
ParentModule_16.3.0.1.0-
----ChildModule1_16.3.0.1.0
----ChildModule2_16.3.0.1.0
----ChildModule3_16.3.0.1.0
Earlier all versions were hardcoded in pom.xml for each module. Later we decided to get these versions from a property file. So i followed below link and it worked fine -
Maven: set property in pom.xml from properties file
now we have a scenario where we want to update version of
childmodule2_16.3.0.1.0 to childModule2_16.6.0.0.0
and
parentModule_16.3.0.1.0 to parentModule_16.6.0.0.0
and rest remains unchanged.
Now the issue we are facing is, when we do full build using parent's pom it doesn't pick jars of some modules because of old versions(16.3.0.1.0).
I have read some blogs where it says maven always pick latest versions.hence the older jars are not getting picked.and some says You always have to specify parent's version. Fortunately, it is inherited as the module's version what is desirable in most cases. Moreover, this parent's version declaration is bumped automatically by Maven Release Plugin.
Can some please help me to understand this. Is there any way to solve this? Thanks in advance.
Below is my Parent pom.xml
<modelVersion>4.0.0</modelVersion>
<groupId>com.myproject</groupId>
<artifactId>parent</artifactId>
<version>${parent-version}</version>
<packaging>pom</packaging>
<modules>
<module>chiled1</module>
<module>child2</module>
</modules>
<dependencies>
<dependency>
<groupId>org.codehaus.mojo</groupId>
<artifactId>properties-maven-plugin</artifactId>
<version>1.0-alpha-2</version>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>properties-maven-plugin</artifactId>
<version>1.0-alpha-2</version>
<executions>
<execution>
<phase>initialize</phase>
<goals>
<goal>read-project-properties</goal>
</goals>
<configuration>
<files>
<file>version.properties</file>
</files>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-failsafe-plugin</artifactId>
<version>2.18.1</version>
<configuration>
<parallel>methods</parallel>
<threadCount>10</threadCount>
</configuration>
</plugin>
<!-- Make assembly -->
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<version>2.5.3</version>
<configuration>
<descriptor>${project.basedir}/assembly.xml</descriptor>
<outputDirectory>${project.basedir}/dist</outputDirectory>
</configuration>
<executions>
<execution>
<id>create-archive</id>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
child2 pom.xml
<groupId>com.myproject.child1</groupId>
<artifactId>child2</artifactId>
<version>${child2-version}</version>
<build>
<finalName>${project.artifactId}-${version}</finalName>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>properties-maven-plugin</artifactId>
<version>1.0-alpha-2</version>
<executions>
<execution>
<phase>initialize</phase>
<goals>
<goal>read-project-properties</goal>
</goals>
<configuration>
<files>
<file>../version.properties</file>
</files>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
version.properties
Earlier -
parent-version=16.3.0.1.0
child1-version=16.3.0.1.0
child2-version=16.3.0.1.0
Now-
parent-version=16.5.0.0.0
child1-version=16.3.0.1.0
child2-version=16.5.0.0.0

I think you are doing something dangerous.
The problem is that if I didn't get you wrong you are trying to build only some of your libs with new versions and some with old ones. In Maven usually if something has a non-SNAPSHOT version it's treated as "released" and hereby stable and it wouldn't try to update that ever again. So this could describe your observation of old versions being used.
Usually you would have your project in a 3.0.1-SNAPSHOT and work with that. In this case you would always get your updates.
Now there are other problems with this approach. You can release a new version with each module having it's own version without any problems. The problem is if you try to release something with a version you already used, things will blow up. Now you could restrict your Maven reactor to release only the modules you want to release and would avoid this problem. Unfortunately you would be running into the next problem as Maven would only update the versions of modules that are part of the current build. So in this case any SNAPSHOT dependency to a module that's not being released would stay a SNAPSHOT and the release plugin would fail for this.
A few years ago I had a customer with the need to release individual modules just the way you are describing it. I did solve the problem, but it wasn't easy. In short: I had to patch the release plugin by changing one or two lines of code, then I had to create a Jenkins Plugin to assist me with configuring the build as it now required an insane input on the commandline. I wrote down everything about :
the release process here:
https://dev.c-ware.de/confluence/display/PUBLIC/Releasing+modules+of+a+multi-module+project+with+independent+version+numbers
the Jenkins Plugin here:
https://dev.c-ware.de/confluence/display/PUBLIC/Developing+a+Jenkins+Plugin+for+the+Maven+Release+Plugin
The code for the Jenkins plugin is located here:
https://github.com/chrisdutz/jenkins-release-plugin

How to use Maven Exec Plugin as Library in another plugin?

I currently am using the Exec Maven Plugin and it works fine with:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<version>1.4.0</version>
<executions>
<execution>
<id>myExec</id>
<goals>
<goal>exec</goal>
</goals>
<phase>generate-sources</phase>
<configuration>
<executable>myExec</executable>
<arguments>
<argument>--foo=${basedir}/src/test/resources/test.xml</argument>
<argument>--output-directory=target/generated-sources/output</argument>
</arguments>
</configuration>
</execution>
</executions>
</plugin>
I am also using the build helper plugin as follows:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>1.10</version>
<executions>
<execution>
<phase>generate-sources</phase>
<goals>
<goal>add-source</goal>
</goals>
<configuration>
<sources>
<source>${project.build.directory}/generated-sources/output</source>
</sources>
</configuration>
</execution>
</executions>
</plugin>
This is incredibly verbose however and I want multiple maven modules to be able to use this program and not have to retype all the exec plugin specific XML along with the builder XML.
Question: How do I possibly combine these 2 into another plugin?
I have used the maven archetype generator to generate a sample maven plugin and have a Mojo class:
#Mojo(name = "touch", defaultPhase = LifecyclePhase.PROCESS_SOURCES)
public class MyMojo
extends AbstractMojo
{
public void execute()
throws MojoExecutionException
{
ExecMojo exec = new ExecMojo();
}
}
And have figured out how to create a new ExecMojo.
Question How do I add the arguments here as I would in the XML above? And how can I integrate these arguments into my plugin?

Instead of creating your own Maven plugin, which may reduce portability and maintenability of your project, you may consider the following approach instead:
Have a common parent pom
Configure the given plugins configuration, optionally in a Maven profile
In the concerned module, point to this parent. Optionally (in case of profiled configuration) activate it on demand when required.
A simple parent pom would look like the following:
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.sample</groupId>
<artifactId>sample-maven-parent</artifactId>
<version>0.0.1-SNAPSHOT</version>
<packaging>pom</packaging>
<properties>
<path.to.myexec>path</path.to.myexec>
</properties>
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<version>1.4.0</version>
<executions>
<execution>
<id>myExec</id>
<goals>
<goal>exec</goal>
</goals>
<phase>generate-sources</phase>
<configuration>
<executable>${path.to.myexec}\myExec</executable>
<arguments>
<argument>--foo=${basedir}/src/test/resources/test.xml</argument>
<argument>--output-directory=${project.build.directory}/generated-sources/output</argument>
</arguments>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>1.10</version>
<executions>
<execution>
<phase>generate-sources</phase>
<goals>
<goal>add-source</goal>
</goals>
<configuration>
<sources>
<source>${project.build.directory}/generated-sources/output</source>
</sources>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
<profiles>
<profile>
<id>myexec-profile</id>
<build>
<plugins>
<!-- optionally move here the configuration above -->
</plugins>
</build>
</profile>
</profiles>
</project>
Note the path.to.myexec property I added, to be overriden in children projects if required, in order to point to the correct relative path.
Then, once installed in your machine (or deployed in your company Maven repository), it can be referenced as following in any concerned Maven projects:
<parent>
<groupId>com.sample</groupId>
<artifactId>sample-maven-parent</artifactId>
<version>0.0.1-SNAPSHOT</version>
</parent>
No need to re-declare the plugin configurations above and its verbose approach. They will be automatically part of the defaul build as part of the inherited build configuration from this parent.
The profiled approach can also be a solution if:
You want to reuse an existing parent pom already used by projects which don't need this configuration
You don't always need this behavior on your build and you want to activate it on demand
In such a case, you can then activate it via, as an example:
mvn clean package -Pmyexec-profile
Given that you already set the parent accordingly and you moved into the profile the configuration above.
Advantages of this approach:
lighter option than writing a new maven plugin (which needs to be written, tested, maintained, distributed, etc.)
easier for consumer modules to customize something: at any moment they can override parent's configuration as an exception
less fragile: just imagine what if another version of one of these plugins provides a bug fix important for you, that's easy to configure an XML, much less easy to change the customized maven plugin etc.
configuration remains centralized, transparently accessible and entry point for further governance
easier troubleshooting: at any moment a consumer module can run mvn help: effective-pom and see the merged full effective pom (as aggregate of parent and current pom) and check what it's actually running
How to skip parent plugin executions in certain modules
A simple (and often used) approach to execute this plugins only in certain modules while having the parent in common with other modules is the following:
Define a new property, let's call it skip.script.generation, with default value to true, defined in the parent pom.
Use this skip property in the skip configuration entry of the plugins above.
Re-define the property only in the concerned modules and set it to false. This will be the only configuration required for their pom.xml files, hence reduced to one line (keeping verbosity really low).
The exec-maven-plugin provides such a skip option, unfortunately the build-helper-maven-plugin doesn't. But that's not blocking us. We can still skip the two executions playing with their phase element, setting it to a non existing phase, like none and as such skipping them. This is suitable because the two executions are actually already attached to the same phase, generate-sources.
For this approach, let's rename our new property to script.generation.phase.
As an example:
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.sample</groupId>
<artifactId>sample-maven-parent</artifactId>
<version>0.0.1-SNAPSHOT</version>
<packaging>pom</packaging>
<properties>
<path.to.myexec>path</path.to.myexec>
<script.generation.phase>none</script.generation.phase>
</properties>
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<version>1.4.0</version>
<executions>
<execution>
<id>myExec</id>
<goals>
<goal>exec</goal>
</goals>
<phase>${script.generation.phase}</phase>
<configuration>
<executable>${path.to.myexec}\myExec</executable>
<arguments>
<argument>--foo=${basedir}/src/test/resources/test.xml</argument>
<argument>--output-directory=${project.build.directory}/generated-sources/output</argument>
</arguments>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>1.10</version>
<executions>
<execution>
<phase>${script.generation.phase}</phase>
<goals>
<goal>add-source</goal>
</goals>
<configuration>
<sources>
<source>${project.build.directory}/generated-sources/output</source>
</sources>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
<profiles>
<profile>
<id>myexec-profile</id>
<build>
<plugins>
<!-- optionally move here the configuration above -->
</plugins>
</build>
</profile>
</profiles>
</project>
Note the <phase>${script.generation.phase}</phase> changes for both plugins. With its default value to none, this property is effectively disabling their executions by default.
In another module you would then have the following:
<parent>
<groupId>com.sample</groupId>
<artifactId>sample-maven-parent</artifactId>
<version>0.0.1-SNAPSHOT</version>
</parent>
<properties>
<script.generation.phase>generate-sources</script.generation.phase>
</properties>
And nothing else. That is. Maven during the build will re-define the property for a certain module and automatically replace it in the configuration inherited from its parent and as such enabling again the two executions above.

What is the best way to avoid maven-jar?

I am using a different plugin (ant4eclipse) to jar my files. What is the best way to avoid the maven-jar plugin from executing?
I tried to remove the <plugin>maven-jar-plugin</plugin>
I tried to <exclude> ** / * < / exclude>
I tried to <skip>true</skip>
None worked

In Maven 3.0.x (I tried 3.0.2) you can disable maven-jar-plugin by binding the default-jar execution to a nonexistent phase, as #bmargulies suggested. Unfortunately that doesn't work in 2.2.1, but you can prevent it from interfering with your own jar by setting an alternative <finalName> and <classifier> for the default-jar execution; it will still create a jar, but it will be set as a secondary artifact for the project and won't overwrite the one you've created. Here's an example that should work in both Maven 2 and Maven 3:
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>test</groupId>
<artifactId>test</artifactId>
<version>0.1-SNAPSHOT</version>
<build>
<plugins>
<plugin>
<artifactId>maven-jar-plugin</artifactId>
<executions>
<execution>
<id>default-jar</id>
<phase>none</phase>
<configuration>
<finalName>unwanted</finalName>
<classifier>unwanted</classifier>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>
Once you've disabled maven-jar-plugin, maven-install-plugin may give you trouble too. In Maven 3 it can be disabled the same as maven-jar-plugin: bind default-install to a nonexistent phase. However, in Maven 2 maven-install-plugin requires that the target/classes directory exist, and it will install the dummy jar when there isn't a primary artifact present.

This should do the trick - notice the use of <id>default-jar</id> and <phase/>.
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>2.4</version>
<executions>
<execution>
<id>default-jar</id>
<phase/>
</execution>
</executions>
</plugin>
</plugins>
</build>

In my case, I only wanted to disable the jar plugin because the jar was empty. You can use the skipIfEmpty option in the plugin configuration
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>3.0.2</version>
<configuration>
<skipIfEmpty>true</skipIfEmpty>
</configuration>
</plugin>

What happens if you declare this?
<packaging>pom</packaging>
Even if it does what you're looking for, be careful. I'm not sure if there could be negative side effects -- such as other maven projects that depend on your jar not being able to locate it.

Using maven 3.3.9, the following worked for me:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>3.1.2</version>
<executions>
<execution>
<id>default-jar</id>
<phase>none</phase>
<configuration>
<finalName>unwanted</finalName>
<classifier>unwanted</classifier>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-install-plugin</artifactId>
<version>3.0.0-M1</version>
<configuration>
<skip>true</skip>
</configuration>
</plugin>
So in case of the maven-jar-plugin, I bound it to a non-existent phase. For the maven-install-plugin, I used the "skip" configuration parameter. The documentation about it says: "Set this to true to bypass artifact installation. Use this for artifacts that does not need to be installed in the local repository."

Explicitly bind the jar plugin to a phase that doesn't exist.

As other's have said, it's not possible to turn it off, other than using <packaging>pom</packaging>, which turns everything off and is probably not what you want.
Even though it will generate twice, a working solution is to bind your jar process to the package phase, as that is guaranteed to run after the default. By overwriting the same JAR file, you'll find that yours is used wherever the original would have been.

I am using a different plugin to jar my files. What is the best way to avoid the maven-jar plugin from executing?
First, the jar:jar goal is bound by default on the package phase for a project with a packaging of type jar. Second, there is no way to unbind a plugin bound to a phase. So, if you are using another plugin(?), either accept to produce 2 JARs or change the packaging (but I don't think this will work well).

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<configuration>
<skip>true</skip>
</configuration>
</plugin>