I'm looking at the plugin section of a pom I'm inspecting and found this:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-docck-plugin</artifactId>
<version>1.0</version>
<executions>
<execution>
<phase>pre-site</phase>
<goals>
<goal>check</goal>
</goals>
</execution>
</executions>
</plugin>
If you observe the execution section you will notice that it does not have an id tag. My question is how is the id tag used by Maven and how the absence of one influences the observed behavior. I looked into Maven tutorials and could infer that id's of different execution phases must be unique, in a pom not necessarily across the inherited poms, but it did not mention how it is utilized.
For Maven 3.0.x at least, when not specified, the ID for an execution is default-goalName. So for the example you have, the ID would be default-check. The value default-cli may also be used to configure command line executions.
The execution IDs are used when creating the effective POM from the POM itself, any parent POMs (including the Maven super POM), and settings.xml. Maven merges configuration for plugin executions having the same ID across these POMs. Here's an example. Assume this plugin config is in a parent POM (only Maven super POM is higher up in the hierarchy.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<executions>
<!-- default-jar is the ID assigned to the jar:jar execution
included automatically by Maven. This demonstrates how we
can tweak the built-in plugin executions to meet our needs.
Note we do not have to specify phase or goals, as those are
inherited. In the example we add a configuration block and
change the values of the <forceCreation> and <finalName>
elements. -->
<execution>
<id>default-jar</id>
<configuration>
<finalName>firstJar</finalName>
<forceCreation>true</forceCreation>
</configuration>
</execution>
<!-- Add an execution of the jar plugin to build a jar with the
same contents but different name. We assign an execution ID.
Because we are not inheriting config for this execution it's our
responsibility to specify phase and goals, as well as the config
we want. Executions are run in order so this one will run after
the default. -->
<execution>
<id>another-jar</id>
<phase>package</phase>
<goals>
<goal>jar</goal>
</goals>
<configuration>
<finalName>duplicateJar</finalName>
</configuration>
</execution>
<!-- Configure plugin behavior if we execute the jar:jar goal
directly from the command line. Don't bind this to a phase;
we don't want to run this as part of the normal lifecycle. -->
<execution>
<id>default-cli</id>
<configuration>
<finalName>cmdLineJar</finalName>
</configuration>
</execution>
</executions>
</plugin>
With the above config:
mvn clean package - builds firstJar.jar and duplicateJar.jar
mvn jar:jar - builds cmdLineJar.jar (note, no clean lifecycle!)
mvn clean jar:jar - removes target dir, builds empty (except for manifest) cmdLineJar.jar; because jar:jar does not run the full lifecycle, just one goal
mvn clean prepare-package jar:jar - runs lifecycle thru prepare-package, then builds a non-empty cmdLineJar.jar
The problem can not be treated with respect to id tag only but notice the different values of it through the examples. This has been tested with maven 3.0.5. Consider the following pom part:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-docck-plugin</artifactId>
<version>1.0</version>
<executions>
<execution>
<id>some-other-other-id</id> <!-- No goal for execution is defined -->
<phase>pre-site</phase>
</execution>
<execution>
<phase>pre-site</phase> <!-- No id for execution is defined -->
<goals>
<goal>check</goal>
</goals>
</execution>
<execution>
<id>some-id</id> <!-- No phase for execution is defined -->
<goals>
<goal>check</goal>
</goals>
</execution>
<execution>
<id>some-other-id</id> <!-- Both id and phase defined -->
<phase>pre-site</phase>
<goals>
<goal>check</goal>
</goals>
</execution>
</executions>
</plugin>
When run mvn clean site from command line it outputs the following:
[INFO] --- maven-docck-plugin:1.0:check (default) # MavenJavaApplication ---
[INFO] Skipping unsupported project: MavenJavaApplication
[INFO] No documentation errors were found.
[INFO]
[INFO] --- maven-docck-plugin:1.0:check (some-other-id) # MavenJavaApplication ---
[INFO] Skipping unsupported project: MavenJavaApplication
[INFO] No documentation errors were found.
Notice that the execution outputs are always in form of:
<plugin-name>:<plugin-version>:<phase> (<execution-id>)
Case 1: No goal for execution is defined
From Build lifecycle basics:
A plugin goal represents a specific task (finer than a build phase) which contributes to the building and managing of a project. It may be bound to zero or more build phases. A goal not bound to any build phase could be executed outside of the build lifecycle by direct invocation. (...) Moreover, if a goal is bound to one or more build phases, that goal will be called in all those phases.
From Guide to configuring plugins: Configuring build plugins:
But if the goal is not bound to any lifecycle phase then it simply won't be executed during the build lifecycle.
From what is quoted, it may be concluded that the execution with id some-other-other-id can be ran from the command line, but that is not so, it can never be ran - it will be covered in the 5th example.
Case 2: No id for execution is defined
The definition of goal and a phase in the first execution is enough for it to get run so it gets assigned a default execution id of value default and it gets executed.
Case 3: No phase for execution is defined
Since the phase is not defined anywhere this execution does not get executed. It can be verified by the fact that the output does not contain the line with its execution id.
Case 4: Both id and phase defined
This execution defines all three: an id, a phase and a goal so it gets executed.
Case 5: CLI execution
If you run (read the syntax in the docck plugin documentation):
mvn docck:check -Doffline=true
it will output:
[INFO] --- maven-docck-plugin:1.0:check (default-cli) # MavenJavaApplication ---
From Guide to configuring default mojo executions:
Starting in Maven 2.2.0, each mojo invoked directly from the command line will have an execution Id of default-cli assigned to it, which will allow the configuration of that execution from the POM by using this default execution Id
You can provide the properties for the goal executed from CLI in three different ways:
in the command line directly
in the plugin configuration
in the execution tag with id of value default-cli
Specifically, the above command is equivalent of running
mvn docck:check
with the pom containing:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-docck-plugin</artifactId>
<version>1.0</version>
<configuration>
<offline>true</offline>
</configuration>
</plugin>
or:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-docck-plugin</artifactId>
<version>1.0</version>
<executions>
<execution>
<id>default-cli</id>
<phase>pre-site</phase>
<goals>
<goal>check</goal>
</goals>
<configuration>
<offline>true</offline>
</configuration>
</execution>
</executions>
</plugin>
This last part comes in handy if you want to keep the global configuration for some common properties in different executions, but you want a complete other set of properties for running from CLI.
Case 6: The default execution
Since the maven-docck-plugin has no default binding I'll cover it with the maven-compiler-plugin. Consider an empty pom with jar packaging. If you run:
mvn clean install
it will trigger the compile phase also and you will see in output:
[INFO] --- maven-compiler-plugin:2.3.1:compile (default-compile) # MavenJavaApplication ---
To cover the value of the id tag, from Guide to Configuring Default Mojo Executions:
Likewise, each mojo bound to the build lifecycle via the default lifecycle mapping for the specified POM packaging will have an execution Id of default-<goalName> assigned to it, to allow configuration of each default mojo execution independently.
If you run mvn help:effective-pom you will find the default execution definition for compiler plugin in output:
<execution>
<id>default-compile</id>
<phase>compile</phase>
<goals>
<goal>compile</goal>
</goals>
</execution>
It gets inherited from super POM for the jar packaging type:
When no packaging is declared, Maven assumes the artifact is the default: jar. The valid types are Plexus role-hints (read more on Plexus for a explanation of roles and role-hints) of the component role org.apache.maven.lifecycle.mapping.LifecycleMapping. The current core packaging values are: pom, jar, maven-plugin, ejb, war, ear, rar, par. These define the default list of goals which execute to each corresponding build lifecycle stage for a particular package structure.
In other words, the above default execution definition is the consequence of a default lifecycle mapping (documentation, definition ) for the compiler-plugin:
The Compiler Plugin has two goals. Both are already bound to their proper phases within the Maven Lifecycle and are therefore, automatically executed during their respective phases.
compiler:compile is bound to the compile phase and is used to compile the main source files.
Uniqueness of an execution id tag
From Guide to configuring plugins.html: Using the executions tag:
Note that while execution id's have to be unique among all executions of a single plugin within a POM, they don't have to be unique across an inheritance hierarchy of POMs. Executions of the same id from different POMs are merged. The same applies to executions that are defined by profiles.
Related
Maven JAR plugin (version 3.0.2) keeps throwing the following error, even for a single invocation of the jar goal:
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-jar-plugin:3.0.2:jar (default) on project test: You have to use a classifier to attach supplemental artifacts to the project instead of replacing them. -> [Help 1]
Here's a (minimal?) pom.xml which demonstrates the problem:
<project xmlns="http://maven.apache.org/POM/4.0.0">
<modelVersion>4.0.0</modelVersion>
<groupId>test</groupId>
<artifactId>test</artifactId>
<version>1.0.0-SNAPSHOT</version>
<build>
<plugins>
<plugin>
<artifactId>maven-jar-plugin</artifactId>
<version>3.0.2</version>
<executions>
<execution>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>
The invocation is just mvn package.
It doesn't seem to matter whether there are any classes/resources at all — the above error message appears anyway.
The problem also appears if two goals are specified (jar and test-jar).
The problem does NOT appear if no goals are specified. But this is not an option, since I really need both jar and test-jar.
According to the documentation, classifier only needs to be specified on multiple invocations of the same goal, and there's a reasonable default for the test-jar goal which I don't intend to change.
Also, the problem doesn't seem to appear on the 2.x line of the JAR plugin.
Did I miss something?
Could anybody please suggest what I am doing wrong?
P.S. The Maven version is 3.3.9.
The Jar Plugin is actually getting executed twice with the configuration:
<plugin>
<artifactId>maven-jar-plugin</artifactId>
<version>3.0.2</version>
<executions>
<execution>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
</plugin>
If you check the logs with such a configuration, you will have something like:
[INFO] --- maven-jar-plugin:3.0.2:jar (default-jar) # test ---
[INFO] Building jar: ...\test\target\test-0.0.1-SNAPSHOT.jar
[INFO]
[INFO] --- maven-jar-plugin:3.0.2:jar (default) # test ---
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
meaning that the plugin was in fact executed twice. What happens, is that the Jar Plugin, in a project that has a packaging of jar has a default execution bound to the package phase. This default execution is the one mentioned in the logs with the ID of default-jar.
When you configured an <execution> in the plugin, you actually configured a new execution, where the jar goal of the plugin is to be invoked. Since the jar goal binds by default to the package phase, that execution is getting executed at that phase, after the default binding inherent to the jar packaging. And since the plugin ran already, it is failing because running it again would actually replace the main artifact already produced during the first run. This error was added in version 3.0.0 of the plugin in MJAR-198, because such a thing happening is very likely a mis-configuration which should be detected early.
As such, the fix is simple: don't have an execution that specifies the goal jar, and let the default one (coming from the jar packaging) do the work. The JAR will still be created, even without the explicit configuration of the jar goal, thanks to the default execution. If you want a test JAR as well, you will still need to configure the plugin to do that with:
<plugin>
<artifactId>maven-jar-plugin</artifactId>
<version>3.0.2</version>
<executions>
<execution>
<goals>
<goal>test-jar</goal>
</goals>
</execution>
</executions>
</plugin>
But note that the goal jar is not specified.
In my case, I have set the execution ID to default-jar, overriding the default execution. Then the error is gone.
<execution>
<id>default-jar</id>
<phase>package</phase>
<goals>
<goal>jar</goal>
</goals>
</execution>
If your logs shows something like:
[INFO] --- maven-jar-plugin:3.0.2:jar (default-jar) # test --
[WARNING] JAR will be empty - no content was marked for inclusion!
Adding a single useless class in src/main/java seems to solve the issue see:
http://maven.40175.n5.nabble.com/quot-mvn-clean-verify-deploy-quot-causes-jar-plugin-to-execute-twice-td5877166.html
Since the above link might be broken as of 2021-09 you might want to try http://mail-archives.apache.org/mod_mbox/maven-users/201608.mbox/thread as an alternative
One reason to have this error may be that the package goal is mistakenly executed twice:
mvn ... package ... package
May happen when the command is built by imperfect scripts :)
A little late but you should add <phase>none</phase> to default-jar execution. this will skip it.
<execution>
<id>default-jar</id>
<phase>none</phase>
</execution>
This will skip the default-jar but others are executed. Make sure you put <phase>package</phase> in the rest of the execution threads.
I can use Maven to compile and test a program
mvn compile
mvn test
Is there a lifecycle command to simply run the program, or generate a script which will run the program?
If you are asking this question, it means it's unclear to you what the Maven lifecycle really is.
There is no lifecycle command, only a build lifecycle, which is made up of different phases.
So to make it clear: there is a build lifecycle, which is made up of phases, which are made up of plugin goals.
When you are invoking Maven with
mvn compile
You are invoking a build phase. In Maven, there is a list of predefined ordered phases. When you invoke a phase, all of the phase before it are also invoked. Invoking a phase means that you are invoking all of the plugins that are bound to this phase. For the compile case, this means it will, among others, invoke the maven-compiler-plugin wich is bound to the compile phase by default.
So to answer your question strictly: no, there is no lifecycle command to do that.
However, you can configure a plugin in your POM, which will be bound to a certain phase, and invoke that phase. For that, you can refer to #manouti's answer which introduces the exec-maven-plugin.
There is no lifecycle phase to do this but you can bind the exec-maven-plugin, specifically the exec:java goal to it. For example, to run the goal on the package phase:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<version>1.4</version>
<executions>
<execution>
<id>run-java</id>
<phase>package</phase>
<goals>
<goal>java</goal>
</goals>
</execution>
</executions>
<configuration>
<mainClass>main.Class</mainClass>
</configuration>
</plugin>
I have a Maven project which includes a Maven plugin (the Liquibase Maven plugin) which exposes different goals.
Two of these goals (update and diff) need different parameters which are in conflict between them (because the semantics of the two is different), so I need to give Maven different properties in the two goal executions.
That's what I've done
<plugin>
<groupId>org.liquibase</groupId>
<artifactId>liquibase-maven-plugin</artifactId>
<version>3.4.1</version>
<!-- This configuration is used for every goal except "diff" -->
<configuration>
<propertyFile>src/main/resources/liquibase.properties</propertyFile>
<promptOnNonLocalDatabase>false</promptOnNonLocalDatabase>
</configuration>
<executions>
<execution>
<id>default-cli</id>
<goals>
<goal>diff</goal>
</goals>
<!-- This configuration is used for the "diff" goal -->
<configuration>
<propertyFile>src/main/resources/liquibaseDiff.properties</propertyFile>
<promptOnNonLocalDatabase>false</promptOnNonLocalDatabase>
</configuration>
</execution>
</executions>
</plugin>
However, this configuration is wrong because for each goal (diff, update of the others) only the liquibaseDiff.properties file is used.
Is there any way to pass different configurations for different goals in Maven?
Configuration of plugins can be done in two different locations:
Globally for all executions. The global configuration is done with the <configuration> element under <plugin>. This configuration in inherited by all executions.
Per execution. This is done using the <configuration> element under <execution>.
In your example, consider this POM:
<plugin>
<groupId>org.liquibase</groupId>
<artifactId>liquibase-maven-plugin</artifactId>
<version>3.4.1</version>
<configuration>
<!-- put the configuration here that is common to all executions -->
</configuration>
<executions>
<execution>
<id>diff</id>
<goals>
<goal>diff</goal>
</goals>
<configuration>
<!-- put the specific configuration of the diff goal here, this will inherit from the global configuration -->
</configuration>
</execution>
<execution>
<id>update</id>
<goals>
<goal>update</goal>
</goals>
<configuration>
<!-- put the specific configuration of the update goal here, this will inherit from the global configuration -->
</configuration>
</execution>
</executions>
</plugin>
The default inheritance behavior is to merge the content of the configuration element according to element name. If the child POM has a particular element, that value becomes the effective value. If the child POM does not have an element, but the parent does, the parent value becomes the effective value.
In case of conflicts, you can control the default inheritance performed by Maven using combine.children and combine.self. Quoting the Maven docs:
combine.children="append" results in the concatenation of parent and child elements, in that order. combine.self="override", on the other hand, completely suppresses parent configuration.
In addition to this, you need to be aware that when executing a Maven command, on the command line, that directly invokes a goal, such as mvn liquibase:diff, it creates a new execution with an id that is default-cli. As such, since the specific configuration above of the goal diff is done in an execution with id diff, it will not be used. This is actually normal, since the same goal of the same plugin could be present in multiple execution blocks with different configuration: which one should be used if it is executed on the command line, without additional information?
Typically, this situation is solved in 2 manners:
Execute on the command line a specific execution, i.e. the one you configured. This is possible since Maven 3.3.1 and you would execute
mvn liquibase:diff#diff
The #diff in the command above refers to the unique <id> of the execution that is configured in the POM.
Bind your execution to a specific phase of the Maven lifecycle, and let it be executed with the normal flow of the lifecycle. This is generally the prefered solution. In the example above, we could, for example, add a <phase>test</phase> in the execution block of the diff execution; and then Maven will execute it when the test phase is ran during the course of the build.
Let's say I have 5 different goals linked to Mojos that I want to be able to bind, named from goal-a to goal-e.
I would like to be able to bind them like maven lifecycle phases, i.e. if I define an execution path and I call a goal, all previous goals on this path are executed beforehand.
I would then have :
goal-a -> { goal-b -> goal-d
{ goal-c -> goal-e
So if I run mvn groupdId:artifactId:myPlugin:goal-d, it executes goal-a, goal-b, goal-d.
If i run the same command with goal-e, it executes goal-a, goal-c, goal-e.
Is there any way to define such bindings ?
You can write a custom plugin quite easily that will accomplish what you are looking for using the Mojo Executor.
For instance, you can write a Mojo for goal-d and in it, you can use the Mojo Executor to execute the goal-a and goal-b Mojos.
You can add execution of your plugin into <build> block or create separate profile for its run, and there define all goals. Here is an example:
<build>
<plugins>
<plugin>
<groupId>your.plugin.group.id</groupId>
<artifactId>your-plugin-artifact-id</artifactId>
<executions>
<execution>
<!-- here you need to specify build phase where your plugin execution will be started -->
<phase>install</phase>
<!-- here you can add all your goals to execute -->
<goals>
<goal>goal-a</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
When you execute phase install on project your plugin will execute its goals.
We are using the maven release plugin on hudson and trying to automate the release process.
The release:prepare works fine. When we try to do the release:perform , it fails because it tries to upload a source artifact twice to the repository.
Things that I tried,
removing the profile which does include the maven source plugin from the super pom ( did not work)
specifying the goals on hudson for release as -P!attach-source release:prepare release:perform. Which I thought will exclude the source plugin from getting executed. (did not work).
tried specifying the plugin phase to some non existent phase in the super pom.(Did not work)
tried specifying the plugin configuration, forReleaseProfile as false. ( guess what?? Did not work too)
It still spits out this error.
[INFO] [DEBUG] Using Wagon implementation lightweight from default mapping for protocol http
[INFO] [DEBUG] Using Wagon implementation lightweight from default mapping for protocol http
[INFO] [DEBUG] Checking for pre-existing User-Agent configuration.
[INFO] [DEBUG] Adding User-Agent configuration.
[INFO] [DEBUG] not adding permissions to wagon connection
[INFO] Uploading: http://xx.xx.xx.xx:8081/nexus/content/repositories/releases//com/yyy/xxx/hhh/hhh-hhh/1.9.40/hhh-hhh-1.9.40-sources.jar
[INFO] 57K uploaded (xxx-xxx-1.9.40-sources.jar)
[INFO] [DEBUG] Using Wagon implementation lightweight from default mapping for protocol http
[INFO] [DEBUG] Using Wagon implementation lightweight from default mapping for protocol http
[INFO] [DEBUG] Checking for pre-existing User-Agent configuration.
[INFO] [DEBUG] Adding User-Agent configuration.
[INFO] [DEBUG] not adding permissions to wagon connection
[INFO] Uploading: http://xx.xxx.xx.xx:8081/nexus/content/repositories/releases//com/xxx/xxxx/xxx/xxx-xxx/1.9.40/xxx-xxx-1.9.40-sources.jar
[INFO] [DEBUG] Using Wagon implementation lightweight from default mapping for protocol http
[INFO] [INFO] ------------------------------------------------------------------------
[INFO] [ERROR] BUILD ERROR
[INFO] [INFO] ------------------------------------------------------------------------
[INFO] [INFO] Error deploying artifact: Authorization failed: Access denied to: http://xx.xxx.xx.xx:8081/nexus/content/repositories/releases/com/xxx/xxx/xxx/xxx-config/1.9.40/xxx-xxx-1.9.40-sources.jar
Any help regarding this will be really appreciated.
Try running mvn -Prelease-profile help:effective-pom.
You will find that you have two execution sections for maven-source-plugin
The output will look something like this:
<plugin>
<artifactId>maven-source-plugin</artifactId>
<version>2.0.4</version>
<executions>
<execution>
<id>attach-sources</id>
<goals>
<goal>jar</goal>
</goals>
</execution>
<execution>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
</plugin>
To fix this problem, find everywhere you have used maven-source-plugin and make sure that you use the "id" attach-sources so that it is the same as the release profile. Then these sections will be merged.
Best practice says that to get consistency you need to configure this in the root POM of your project in build > pluginManagement and NOT in your child poms. In the child pom you just specify in build > plugins that you want to use maven-source-plugin but you provide no executions.
In the root pom.xml:
<build>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-source-plugin</artifactId>
<executions>
<execution>
<!-- This id must match the -Prelease-profile id value or else sources will be "uploaded" twice, which causes Nexus to fail -->
<id>attach-sources</id>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</pluginManagement>
</build>
In the child pom.xml:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-source-plugin</artifactId>
</plugin>
</plugins>
</build>
I know this question is old but it was google hit #1 today so I'll add my answer appropriate for recent versions of maven 3.
The symptom is that sources and javadoc jars are deployed twice when doing a release build with some versions of maven 3. If you're using maven to deploy your artifacts to a Sonatype Nexus repository that only allows a release artifact to be uploaded once (which is totally reasonable behavior), the build fails when the second upload attempt is rejected. Argh!
Maven versions 3.2.3 thru 3.3.9 have bugs - see https://issues.apache.org/jira/browse/MNG-5868 and https://issues.apache.org/jira/browse/MNG-5939. Those versions generate and deploy sources and javadoc jars twice when doing a release.
If I read the Maven issue tracker correctly, those bugs are not scheduled for fix as of this writing (the burned 3.4.0 release probably affected these).
Instead of a complex tweak to my pom, my simple workaround was to fall back to Maven version 3.2.1.
Just having hit the same problem, I analyzed it a bit. mvn release:perform evaluates the release.properties file, then checks out the tag in a temporary directory and invokes there something like
/usr/bin/mvn -D maven.repo.local=... -s /tmp/release-settings5747060794.xml
-D performRelease=true -P set-envs,maven,set-envs deploy
I tried to reproduce this – manually checked out the tag produced by release:prepare and invoked this:
mvn -D performRelease=true -P set-envs,maven,set-envs deploy
I got the same result: It was trying to upload the -sources.jar twice.
As noted by qualidafial in a comment, setting performRelease=false instead omits one of the two attachments of the same file.
I don't really have an idea how the deploy plugin (or any other plugin) uses this property.
We can provide this parameter as a configuration to the maven-relase-plugin:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-release-plugin</artifactId>
<version>2.3.2</version>
<configuration>
<useReleaseProfile>false</useReleaseProfile>
</configuration>
</plugin>
</plugins>
</build>
I now added the <useReleaseProfile>false</useReleaseProfile> line to all the POMs, and it looks like releasing now works without an error message.
I have been struggeling with this issue for a while and have finally been able to resolve it in our infrastructure. The answers here didn't help me, as we didn't have multiple executions of the source plugin goals and the configuration seemed fine to us.
What we did miss out was to bind the execution of the source plugin to a phase. Extending the example by Bae, including the line <phase>install</phase> to the execution resolved the issue for us:
<plugin>
<artifactId>maven-source-plugin</artifactId>
<version>2.0.4</version>
<executions>
<execution>
<id>attach-sources</id>
<phase>install</phase>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
</plugin>
I suspect the solution lies in this answer here; different plugins seem to be invoking the jar goal / the attach-sources execution. By binding our execution to a certain phase, we force our plugin only to be run in this phase.
This was happening to me when running
mvn install deploy
I avoided the problem by instead running
mvn deploy
(which implies install). In my case only one artifact was being attempted to be uploaded twice, and that was a secondary artifact (maven-jar-plugin was setup to build a secondary jar in addition to the one built by the default-jar execution).
TL;DR
Disable execution with id attach-sources fixes this problem, if you cannot modify your parent poms.
--
This answer is a supplementary for #Bae's answer:
https://stackoverflow.com/a/10794985/3395456
My problem is the same, when running mvn -Prelease-profile help:effective-pom, I have two execution sections for maven-source-plugin
<plugin>
<artifactId>maven-source-plugin</artifactId>
<version>2.0.4</version>
<executions>
<execution>
<id>attach-sources</id>
<goals>
<goal>jar</goal>
</goals>
</execution>
<execution>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
</plugin>
The top voted answer just recommends a best practice to remove unnamed (anonymous) execution to avoid duplicated binding. But what if I cannot remove it, because I cannot change the parent pom?
There is one way to disable one execution, not the anonymous one, but the one with id attach-source. And it also works for uploading xx-javadoc.jar twice.
So under my pom.xml, I can explictly override the plugins settings, by disabling the execution with id attach-source.
<!-- Fix uploading xx-source.jar and xx-javadoc.jar twice to Nexus -->
<!-- try to disable attach-sources, attach-javadocs execution (bind its phase to none) -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-source-plugin</artifactId>
<executions>
<execution>
<id>attach-sources</id>
<phase>none</phase>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<executions>
<execution>
<id>attach-javadocs</id>
<phase>none</phase>
</execution>
</executions>
<inherited>true</inherited>
</plugin>
References:
Is it possible to override executions in maven pluginManagement?
I don't think the probem is in the release plugin, I think you've got the xxx-sources.jar attached two times - that's why the duplicate upload. Why is there a duplicate attachment is hard to tell without seeing the POM. Try running mvn -X and checking the log for who attaches xxx-source.jar another time.
In any case, a good workaround on Nexus would be having a staging repository where you can upload releases several times - and when everything's ready you just close/promote the staging repo. Check the Sonatype OSS setup for an example.
I had the same problem. Basically, the error message is issued when an artifacts is sent to Nexus twice. This may be twice to the same Nexus repository or even across different repositories within the same Nexus.
However, the reasons for such a misconfiguration may vary. In my case, the artifacts were uploaded correctly during a mvn clean deploy build step in Jenkins, but then failed when a second deploy had been attempted. This second deploy had been configured in a Jenkins post build step "Publish artifacts in Maven repository".
Maven plugins in parent and child poms should not have execution. As per standard convention, define all plugin with execution/goals in parent pom in plugin management section. Child pom should not redefine above details, but mention only the plugin (with artifactId, and version) that needs to be executed.
I had similar issue with maven-assembly-plugin with parent pom as below:
<build>
<pluginManagement>
<plugins>
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<version>2.6</version>
<configuration>
<descriptors>
<descriptor>src/assembly/assembly.xml</descriptor>
</descriptors>
</configuration>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</pluginManagement>
</build>
And Child pom had maven-assembly-plugin as below:
<build>
<plugins>
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<version>2.2-beta-5</version>
<configuration>
<finalName>xyz</finalName>
<descriptors>
<descriptor>src/assembly/assembly.xml</descriptor>
</descriptors>
</configuration>
<executions>
<execution>
<id>xyz-distribution</id>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
Removing the <executions> from child pom rectified the issue.
The effective pom had 2 executions performed causing the duplicate install to Nexus repo.
FWIW this issue was breaking our build for a while and the answer was none-of-the-above.
Instead I had foolishly set the seemingly innocuous appendAssemblyId to false in a maven-assembly-plugin for an artifact that gets attached (read deployed, released) with our main artifact. E.g.:
<execution>
<id>ci-groovy-distrib</id>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
<configuration>
<descriptorRefs>
<descriptorRef>my-extra-assembly</descriptorRef>
</descriptorRefs>
<!-- This is the BUG: the assemblyID MUST be appended
because it is the classifier that distinguishes
this attached artifact from the main one!
-->
<appendAssemblyId>false</appendAssemblyId>
<!-- NOTE: Changes the name of the zip in the build target directory
but NOT the artifact that gets installed, deployed, releaseed -->
<finalName>my-extra-assembly-${project.version}</finalName>
</configuration>
</execution>
In summary:
the assembly plugin uses the assemblyId as the classifier for the artifact, hence an essential part of it's unique GAV coordinates in maven terms (actually it's more like GAVC coordinates - C is the classifier).
the name of the file installed, deployed, or released is actually built from these coordinates. It is not the same as the filename you see in your target directory. That's why your local build looks good, but your release will fail.
The stupid element only determines the local build artifact name and plays no part in the rest of it. It's a complete red-herring.
Summary of the summary:
The 400 error from Nexus was because our extra attached artifact was being uploaded over top of the main artifact, since it had the same name as the main artifact, because it had the same GAVC coordinates as the main artifact, because I removed the only distinguishing coordinate: the classifier derived automatically from the assemblyId.
The investigation to find this was a long and tortuous path the answer was right there all along in the docs for maven-assembly:
appendAssemblyId
boolean
Set to false to exclude the assembly id
from the assembly final name, and to create the resultant assembly
artifacts without classifier. As such, an assembly artifact having the
same format as the packaging of the current Maven project will replace
the file for this main project artifact.
Default value is: true.
User property is: assembly.appendAssemblyId.
From http://maven.apache.org/plugins/maven-assembly-plugin/single-mojo.html#attach
The extra bold is mine. The docs should have a big flashing warning here: "Set this to false and abandon all hope"
I got some help from this answer about a different problem maven-assembly-plugin: How to use appendAssemblyId
The explanation there from tunaki really helped.
I faced similar issue. Artifacts were getting deployed twice and the resultant build was failing.
Checked and found that the issue was in Jenkins Script. The settings.xml was called twice. Like:
sh "mvn -s settings.xml clean deploy -s settings.xml deploy -U .....
which caused the issue.
Updated this line and it worked like a charm:
sh "mvn clean deploy -s settings.xml -U .....
with nexus thix configuratio nworked for me
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-release-plugin</artifactId>
<configuration>
<useReleaseProfile>false</useReleaseProfile>
</configuration>
</plugin>
I configured the maven release plug-in with releaseProfile=false and dont execute the source artifacts profile. Which did the trick.
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-release-plugin</artifactId>
<version>2.1</version>
<configuration>
<arguments>-P!source-artifacts</arguments>
<useReleaseProfile>false</useReleaseProfile>
<goals>-Dmaven.test.skip=true deploy</goals>
</configuration>
</plugin>
</plugins>
</build>