Develop Reference

Publish from internal nexus to maven central

I have an internal nexus that contains all the artifacts that we build.
Once an artifact is tested, I want to take the sane artifact and deploy it to Maven Central without rebuilding it.
I know that I might be able to do that using mvn deploy:deploy-file but it seems complicated.
Is there an easy way to do it?
Note: due to historical reasons,we don't use SNAPSHOT versions. All versions are in the style of artifact-name-X.Y.Z.jar were X.Y.Z is the version number. We have an internal tool that can be queried for sanity.

I've ended using an approach similar to what they have in here:
https://central.sonatype.org/pages/manual-staging-bundle-creation-and-deployment.html
So, if I had the following files:
ossrh-test-1.2.pom
ossrh-test-1.2.jar
ossrh-test-1.2-javadoc.jar
ossrh-test-1.2-sources.jar
I've invoked this command for the JAR:
mvn gpg:sign-and-deploy-file -Durl=https://oss.sonatype.org/service/local/staging/deploy/maven2/ -DrepositoryId=ossrh -DpomFile=ossrh-test-1.2.pom -Dfile=ossrh-test-1.2.jar
And the following commands for the sources and JavaDocs:
mvn gpg:sign-and-deploy-file -Durl=https://oss.sonatype.org/service/local/staging/deploy/maven2/ -DrepositoryId=ossrh -DpomFile=ossrh-test-1.2.pom -Dfile=ossrh-test-1.2-sources.jar -Dclassifier=sources
mvn gpg:sign-and-deploy-file -Durl=https://oss.sonatype.org/service/local/staging/deploy/maven2/ -DrepositoryId=ossrh -DpomFile=ossrh-test-1.2.pom -Dfile=ossrh-test-1.2-javadoc.jar -Dclassifier=javadoc
Last but not least, since I had to create fake sources and javadoc jars I've just taken a jar, unzipped it, put a readme file inside of it instead of the old content, updated the manifest and zipped it again. Then I've uploaded it as my fake sources/javadoc jars.

Let me assume you have not only x.y.z version of binaries, but also scm tag for this version.
If so, you can give a try to the following CI job:
<scm> checkout <YOUR TAG>
<scm> clean -d -x -f
mvn maven-dependency-plugin:get -Pcustom-deployment -DexecutionId=resolve-sane-binaries
mvn maven-deploy-plugin:deploy -Pcustom-deployment -DexecutionId=deploy-sane-binaries
with profile in your pom.xml:
<profiles>
<profile>
<id>custom-deployment</id>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>3.1.2</version>
<executions>
<execution>
<id>resolve-sane-binaries</id>
<goals>
<goal>get</goal>
</goals>
<configuration>
<artifactItems>
<artifactItem>
<groupId>${project.groupId}</groupId>
<artifactId>${project.artifactId}</artifactId>
<version>${project.version}</version>
<type>${project.packaging}</type>
<outputDirectory>${project.build.directory}</outputDirectory>
<destFileName>${project.build.finalName}</destFileName>
</artifactItem>
...
</artifactItems>
...
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-deploy-plugin</artifactId>
<version>2.8.2</version>
<executions>
<execution>
<id>deploy-sane-binaries</id>
<goals>
<goal>deploy-file</goal>
</goals>
<configuration>
...
</configuration>
</execution>
<executions>
<plugin>
</plugins>
It's just an idea, not a code I've really tested. But hope it'll help.

Java / mvn code coverage AND redundancy?

Have a monolthic app that runs JUnit tests through Surefire and Maven. I see several options out there that will tell me about code coverage, but I'm trying to find something a little different:
Specifically, I'd like to run a mvn build that generates a report (or use an Eclipse plugin that does the same) that will give me a way to see what tests are all pretty much doing the same thing, in addition to the parts of the app that do not have good coverage. Does something like this exist?

I doesn't cover the redundancy part, but for the coverage you may use Jacoco, it's easy to setup with maven:
<build>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-site-plugin</artifactId>
<version>3.6</version>
</plugin>
</plugins>
</pluginManagement>
<plugins>
<plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
<version>0.7.7.201606060606</version>
<executions>
<execution>
<id>default-prepare-agent</id>
<goals>
<goal>prepare-agent</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
<reporting>
<excludeDefaults>true</excludeDefaults>
<outputDirectory>${project.build.directory}/site</outputDirectory>
<plugins>
<plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
</plugin>
</plugins>
</reporting>
To generate the report, type mvn site. The reports will be created under target/site.

To combine with #alexbt answer you can utilize the report you have with Jacoco but plug that report into SonarQube (you can easily install it locally) then get the SonarLint Eclipse plugin that connects to the local SonarQube instance to get the integration you want.
In addition you get copy and paste detection and some redundant code checks. I say some because public methods are never marked as redundant.
Here are an examples of an online report with and without major problems
https://sonarcloud.io/dashboard?id=org.apache.maven:maven
https://sonarqube.com/dashboard?id=net.trajano.mojo:batik-maven-plugin
https://sonarcloud.io/component_measures/domain/Coverage?id=net.trajano.jetng:jetng
One bonus is you can centralize the rules for your team.

How can I speed up maven builds of JavaFX application?

My problem can be reproduced by creating a new project in Netbeans 8:
New Project >> Maven >> JavaFX Application
Then adding the org.springframework spring-context dependency.
Build times go up from a few seconds to more than half a minute, most of it due to running javafxpackager.
I can live with slow release builds but how can I speed up my development builds?
This is my pom.xml:
<?xml version="1.0" encoding="UTF-8"?>
<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.mycompany</groupId>
<artifactId>mavenproject1</artifactId>
<version>1.0-SNAPSHOT</version>
<packaging>jar</packaging>
<name>mavenproject1</name>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<mainClass>com.mycompany.mavenproject1.MainApp</mainClass>
</properties>
<organization>
<!-- Used as the 'Vendor' for JNLP generation -->
<name>Your Organisation</name>
</organization>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.6</version>
<executions>
<execution>
<id>unpack-dependencies</id>
<phase>package</phase>
<goals>
<goal>unpack-dependencies</goal>
</goals>
<configuration>
<excludeScope>system</excludeScope>
<excludeGroupIds>junit,org.mockito,org.hamcrest</excludeGroupIds>
<outputDirectory>${project.build.directory}/classes</outputDirectory>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<version>1.2.1</version>
<executions>
<execution>
<id>unpack-dependencies</id>
<phase>package</phase>
<goals>
<goal>exec</goal>
</goals>
<configuration>
<executable>${java.home}/../bin/javafxpackager</executable>
<arguments>
<argument>-createjar</argument>
<argument>-nocss2bin</argument>
<argument>-appclass</argument>
<argument>${mainClass}</argument>
<argument>-srcdir</argument>
<argument>${project.build.directory}/classes</argument>
<argument>-outdir</argument>
<argument>${project.build.directory}</argument>
<argument>-outfile</argument>
<argument>${project.build.finalName}.jar</argument>
</arguments>
</configuration>
</execution>
<execution>
<id>default-cli</id>
<goals>
<goal>exec</goal>
</goals>
<configuration>
<executable>${java.home}/bin/java</executable>
<commandlineArgs>${runfx.args}</commandlineArgs>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.1</version>
<configuration>
<source>1.7</source>
<target>1.7</target>
<compilerArguments>
<bootclasspath>${sun.boot.class.path}${path.separator}${java.home}/lib/jfxrt.jar</bootclasspath>
</compilerArguments>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.16</version>
<configuration>
<additionalClasspathElements>
<additionalClasspathElement>${java.home}/lib/jfxrt.jar</additionalClasspathElement>
</additionalClasspathElements>
</configuration>
</plugin>
</plugins>
</build>
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<version>4.0.6.RELEASE</version>
</dependency>
</dependencies>
Thanks!
Daniel

You could define the plugin in a profile that is inactive by default. Then, in order to make the production build, you would have to manually specify the activation of that profile (or activate it in any other standard way).
You pom would be something like (only diffs shown):
<?xml version="1.0" encoding="UTF-8"?>
<project ...>
...
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
...
<executions>
<!-- take this out of here
<execution>
<id>unpack-dependencies</id>
...
</execution>
-->
<execution>
...
</execution>
</executions>
</plugin>
...
</plugins>
</build>
<profiles>
<profile>
<id>javafxpackager</id>
<build>
<plugins>
<!-- INSERT THE exec-maven-plugin HERE, ONLY
WITH THE unpack-dependencies EXECUTION -->
</plugins>
</build>
</profile>
</profiles>
</project>
In production run mvn ... -Pjavafxpackager

To complete Nikos' answer, this is the configuration of the maven-assembly-plugin which creates the archive for normal builds.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-assembly-plugin</artifactId>
<configuration>
<appendAssemblyId>false</appendAssemblyId>
<archive>
<manifest>
<mainClass>${mainClass}</mainClass>
</manifest>
</archive>
<descriptorRefs>
<descriptorRef>jar-with-dependencies</descriptorRef>
</descriptorRefs>
</configuration>
<executions>
<execution>
<id>my-assembly</id>
<phase>package</phase>
<goals>
<goal>assembly</goal>
</goals>
</execution>
</executions>
</plugin>

above solutions dont work. The problem has nothing to do with javafxpackager whatsoever. The cause lies in the maven standard configuration. On every project run Maven performs a project clean by default. This deletes the targets/classes/ folder. Thats the same folder where all the unpacked jar files of your dependencies are placed. If those get deleted on every new run then they have to be unpacked over and over again. Anyway, heres how you can prevent the clean from happening:
<plugin>
<artifactId>maven-clean-plugin</artifactId>
<version>2.4.1</version>
<configuration>
<skip>true</skip>
</configuration>
</plugin>
Add this to your POM.xml. Make sure you get the version correct You can check the version of your maven clean plugin in the effective pom (thats parent pom + project POM combined). In netbeans you can watch the readonly effective pom.xml under the effective tab when you've opened the pom.xml file of your project.
please give me a few +1's i want to get 50 points so that i can finally comment on other peoples answers. Thank you!
EDIT:
Also add skip to default-cli to avoid errors
<execution>
<id>default-cli</id>
<goals>
<goal>exec</goal>
</goals>
<configuration>
<skip>true</skip>
<executable>${java.home}/bin/java</executable>
<commandlineArgs>${runfx.args}</commandlineArgs>
</configuration>
</execution>
EDIT 2:
For those of you who would like to retain the ability to clean heres another method to prevent the maven plugin from deleting all jar files:
<plugin>
<artifactId>maven-clean-plugin</artifactId>
<version>2.4.1</version>
<configuration>
<excludeDefaultDirectories>true</excludeDefaultDirectories>
<filesets>
<!-- delete directories that will be generated when you
start the develpment server/client in eclipse
-->
<fileset>
<directory>target/classes</directory>
<excludes>
<exclude>**/*</exclude>
</excludes>
</fileset>
</filesets>
</configuration>
Again, make sure is correct

TL;DR:
To avoid unpacking dependencies, you don't need to modify the default pom.xml at all. Just change what Netbeans calls when you press Run (or Debug). In nbactions.xml change:
runfx.args: Replace -jar "${project.build.directory}/${project.build.finalName}.jar" with -cp %classpath ${mainClass}. This way, the exec goal will not try to execute any jar but rather run your project from the target/classes directory. So no need to build the jar at all.
goals: replace the "package" goal with "process-classes" (or "test" or any phase you want). We don't need a jar so no need to run the package phase. And no package phase also means no unpacking/repacking etc.
If you ever need the jar file with all the dependencies, just choose "clean and build" in Netbeans or run mvn clean install.
Background:
What happens when you press run in the standard Netbeans JavaFX maven project is:
clean package exec - defined in nbactions.xml, configured in pom.xml:
clean: as usual - deletes the target directory
package:
first as usual - copies resources and compiles sources to target/classes and packs that all to a jar without dependencies
maven-dependency-plugin unpacks all the dependency jar files to target/classes
exec-maven-plugin:unpack-dependencies (the id "unpack-dependencies" is missleading, should be something like "jar-with-dependencies") executes javapackager which builds a jar with dependencies overwriting the first jar
exec:
executes java with ${runfx.args} as arguments (defined in nbactions.xml) i.e. runs the jar
What happens after the changes above:
clean process-classes exec - defined in nbactions.xml, configured in pom.xml:
clean: as usual - deletes the target directory
process-classes:
as usual - copies resources and compiles sources to target/classes
exec:
executes java with ${runfx.args} as arguments (defined in nbactions.xml) i.e. runs the class target/classes/path/to/your/MainClass
Even better:
You may want remove the "clean" goal from nbactions.xml. This way, all the resource files won't be copied each time over and over (although the resource plugin will still keep saying "Copying X resources" - see the comments under https://stackoverflow.com/a/33700970/3519572).
Now, you may also want to only recompile changed classes rather than the whole project by adding useIncrementalCompilation=false (e.g. like <goal>org.codehaus.mojo:exec-maven-plugin:1.2.1:exec -Dmaven.compiler.useIncrementalCompilation=false</goal>). But be sure to read https://stackoverflow.com/a/49700942/3519572!
Therefore, you may also want to add a toolbar button to the "clean" goal to be able to run it manually easily at any time: https://stackoverflow.com/a/26546551/3519572.
BTW:
Finally, you might want to change the NetBeans generated pom.xml anyway. At least my NB 8.2 refers to the deprecated javafxpackager (rename to javapackager). Also the part <bootclasspath>..../lib/jfxrt.jar</bootclasspath> doesn't seem to be necessary with java 8. It actually breaks my build if I run it from the terminal. Removing it seems to fix it and doesn't seem to cause any trouble if started from NB.

You can also use parallel maven build feature to speed up.
By default, Maven does not utilize the full power of your hardware. It builds all modules sequentially rather than in parallel. However, often your project setup does not require it to be sequential. Often you can command Maven to analyze your project including the dependency graph and build the project in parallel where possible. You can either specify the exact number of threads to use for building your project or use a portable version of the parameter and specify the number of thread in terms of CPUs available on the machine.
mvn -T 4 install -- will use 4 threads
mvn -T 1C install -- will use 1 thread per available CPU core
See for more details: https://zeroturnaround.com/rebellabs/your-maven-build-is-slow-speed-it-up/

Maven: Why does adding test source via build helper not work when generating eclipse project?

Our maven pom.xml specifies to add an additional source and test-source folder if a certain profile (here "java8") is activated. The corresponding part of the pom looks like the following
<profile>
<id>java8</id>
....
<build>
<plugins>
....
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>1.8</version>
<executions>
<execution>
<id>add-test-source</id>
<phase>generate-test-sources</phase>
<goals><goal>add-test-source</goal></goals>
<configuration>
<sources>
<source>src/test/java8</source>
</sources>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
According to http://mojo.codehaus.org/build-helper-maven-plugin/usage.html this appears to be the correct specification.
Running mvm install -P java8 I see that the additional tests are performed as expected.
However, running mvm eclipse:eclipse -P java8 the additional test source folder does not appear in eclipse .classpath.
Question: How do I have to configure maven to add the test source folder to the eclipse configuration? Is the above behavior a bug or a misconfiguration?

Having spent some time experimenting with this, I can give a partial answer to my own question (hopefully saving some time of other developers):
If one uses
<phase>generate-sources</phase>
<goals><goal>add-test-source</goal></goals>
instead of
<phase>generate-test-sources</phase>
<goals><goal>add-test-source</goal></goals>
then the test source folder is added to the eclipse .classpath (and it is added as a test folder). I.e. I am executing "add-test-source" in a different phase now.
In other words the profile looks like this:
<profile>
<id>java8</id>
....
<build>
<plugins>
....
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>1.8</version>
<executions>
<execution>
<id>add-test-source</id>
<phase>generate-sources</phase>
<goals><goal>add-test-source</goal></goals>
<configuration>
<sources>
<source>src/test/java8</source>
</sources>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
This looks like a "workaround". It still contradicts the specification on http://mojo.codehaus.org/build-helper-maven-plugin/usage.html

rather than using eclipse:eclipse, you can use the http://www.eclipse.org/m2e/ plugin to open maven pom.xml projects.
Once you install that plugin in maven you will be able to take advantage of the m2e maven plugin, which can map any maven phase into the eclipse build life cycle.
in our example you will need to add something like this to your pom.xml:
<pluginManagement>
<plugins>
<plugin>
<groupId>org.eclipse.m2e</groupId>
<artifactId>lifecycle-mapping</artifactId>
<version>1.0.0</version>
<configuration>
<lifecycleMappingMetadata>
<pluginExecutions>
<pluginExecution>
<pluginExecutionFilter>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<versionRange>[1.0,)</versionRange>
<goals>
<goal>add-test-source</goal>
</goals>
</pluginExecutionFilter>
<action>
<execute>
<runOnIncremental>true</runOnIncremental>
</execute>
</action>
</pluginExecution>
</pluginExecutions>
</lifecycleMappingMetadata>
</configuration>
</plugin>
</plugins>
</pluginManagement>
Important
this will only work if you install the m2e plugin and use it to open maven projects.

The way I see it, the plugin is working as expected.
When you run mvn install -P java8, you are invoking the phase install. In effect, maven executes all the phase prior to install, including generate-test-sources phase and test phase... before it really executes install. Because your plugin's goal is bound to generate-test-sources phase, that's why in this case you see your tests added in the class-path and run.
When you run mvn eclipse:eclipse -P java8, however, you are invoking a plugin's goal (in particular, eclipse goal of eclipse plugin), not a build life-cycle (phase). According to the eclipse plugin's documentation, only the generate-resources phase will be invoked. Be noted that generate-resources doesn't not "include" generate-test-sources (see more here), so in this case, your build-helper plugin does not get called.
If I guess correctly, you're trying to run your test in Eclipse with the profile java8 enabled. In that case, one way to do it (without having to work around) is right click on your project, click Maven, in the Active Maven Profile input box type in java8 ->OK. Now right click in your project and choose Run As -> JUnit Test (or whatever test framework you're using). Make sure you use the latest Eclipse version (Kepler 4.3.1 as of now) as it has a built-in m2e plugin which has improved a lot from the original m2e.

I'm experiencing the same issue as you Christian Fries and I came to the same conclusion as you about binding the add-test-source goal to the generate-sources phase instead of the generate-test-sources phase.
The problem is that when we run mvn eclipse:eclipse, we are actually directly calling a plugin so only that plugin will run. The reason the generate-sources phase is executed is explained in the plugin's doco (http://maven.apache.org/plugins/maven-eclipse-plugin/eclipse-mojo.html):
Invokes the execution of the lifecycle phase generate-resources prior to executing itself.
What we want is to be able to tell the plugin to execute the generate-test-sources phase before itself and then run. Note that maven will run all the phases up to and including the one you specify (http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html) so we don't need to say run generate-sources AND generate-test-sources because simply specifying the latter is enough. Anyway, we can test this situation by running (the order matters):
mvn generate-test-sources eclipse:eclipse
...and for me, this did exactly as we expected. You can see from the output that the build-helper-maven-plugin is run to add the test sources and THEN the maven-eclipse-plugin runs and picks it up.
Now we have a new problem because AFAIK you can only bind a plugin to a phase (so it runs when the phase is run) and not the other way around.
The (sort of) solution is to bind the build-helper-maven-plugin and the maven-eclipse-plugin (in that order, so define the plugins in your POM in that order) to the generate-test-sources phase and then instead of running mvn eclipse:eclipse, run:
mvn generate-test-sources
So we have a POM that looks like:
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>1.8</version>
<executions>
<execution>
<id>add-test-source</id>
<phase>generate-test-sources</phase>
<goals>
<goal>add-test-source</goal>
</goals>
<configuration>
<sources>
<directory>src/test/java8</directory>
</sources>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-eclipse-plugin</artifactId>
<version>2.9</version>
<executions>
<execution>
<phase>generate-test-sources</phase>
<goals>
<goal>eclipse</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
I know it's not perfect because people will still run mvn eclipse:eclipse and cry when it doesn't work. Also, the maven-eclipse-plugin will run as part of anything that runs the generate-test-sources phase (i.e. mvn clean install) which isn't so bad if it doesn't steamroll custom settings people have but if it is a problem you could move this stuff into a profile, bind it to a different phase that doesn't run as part of a build (like clean) or create a new lifecycle phase.

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>