There is lots of duplicates codes including:
Duplicates within file
Duplicates within package
Duplicates around multiple packages
Duplicates around separate Maven Modules
Is there any way to find duplicate codes using Netbeans 8+ or Netbeans Plugins or Maven Plugin with Netbeans or Standalone tools similar to Intellij?
I am unable to find documentation of same.
I have found PMD in Maven but unable to link with Netbeans 8.2 and We are only supposed to use Netbeans
You can find duplicated code for a NetBeans Maven project using the Apache Maven PMD Plugin. Simply add the following to your project's pom.xml:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-pmd-plugin</artifactId>
<version>2.7.1</version>
<executions>
<execution>
<goals>
<goal>check</goal>
<goal>cpd-check</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
<reporting>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-pmd-plugin</artifactId>
<version>2.7.1</version>
</plugin>
</plugins>
</reporting>
When you build your project PMD's copy paste detector (CPD) will be run, and write its results to file {project directory}\target\cpd.xml. If no duplication is found that file looks like this:
<?xml version="1.0" encoding="UTF-8"?>
<pmd-cpd>
</pmd-cpd>
However, if duplication is found the file looks similar to this:
<?xml version="1.0" encoding="UTF-8"?>
<pmd-cpd>
<duplication lines="162" tokens="608">
<file line="95" path="D:\NetBeansProjectsJava9\checkduplication\src\main\java\com\unthreading\checkduplication\ParseJavadoc.java"/>
<file line="258" path="D:\NetBeansProjectsJava9\checkduplication\src\main\java\com\unthreading\checkduplication\ParseJavadoc.java"/>
<codefragment>
<![CDATA[
...details of the duplicated code....
]]>
</codefragment>
</duplication>
</pmd-cpd>
After updating the POM as described above, a very simple way to verify that duplication detection is working is to copy/paste a large method within some class, and then give the pasted method another name so that the code still compiles. I tried that and got the following result in the Output window:
maven-pmd-plugin:2.7.1:cpd-check (default) # checkduplication ---
BUILD FAILURE
Total time: 2.689 s Finished at: 2018-02-15T17:06:23-05:00 Final
Memory: 20M/70M
Failed to execute goal
org.apache.maven.plugins:maven-pmd-plugin:2.7.1:cpd-check (default) on
project checkduplication: You have 1 CPD duplication. For more details
see:D:\NetBeansProjectsJava9\checkduplication\target\cpd.xml -> [Help
1]
A couple of final points:
Specifying <goal>cpd-check</goal> (as I did) causes the build to fail when duplication is detected, but alternative goals can be specified.
There are more recent versions of maven-pmd-plugin than 2.7.1, but that is the most recent version where copy/paste detection works out of the box. More recent versions may work after playing with the configuration, but I didn't try that.
If I have two dependencies which are the same in the same pom, I want the build to fail. Currently I can detect it happening with the Maven Dependency Plugin's "analyze-duplicate". However, there's no option to failOnWarning like some of the others (plus, it prints at Info level, not Warning). Is there an alternative to extending this?
Generally, when you want the build to fail for some reason, the good plugin to look into the Maven Enforcer Plugin. This plugin can be configured with a set of rules that, when verified, will fail the build.
In this case, it would need to be a rule that checks for duplicate dependencies, and there is a built-in rule just for that: <banDuplicatePomDependencyVersions>. As such, you could have
<plugin>
<artifactId>maven-enforcer-plugin</artifactId>
<version>1.4.1</version>
<executions>
<execution>
<id>enforce-no-duplicate-dependencies</id>
<goals>
<goal>enforce</goal>
</goals>
<configuration>
<rules>
<banDuplicatePomDependencyVersions/>
</rules>
</configuration>
</execution>
</executions>
</plugin>
This rule is unfortunately not documented (yet, it will be in the next version, see MENFORCER-259), but it exists since version 1.3 of the plugin (MENFORCER-152).
What this rule does is checking that there are no 2 duplicate declaration with the same 'dependencies.dependency.(groupId:artifactId:type:classifier)'; which is to say that two declared dependencies with the same group id and artifact id declared in the POM will have to have a different type and/or classifier.
When I am importing my maven project in my eclipse, I am getting this error:
Plugin execution not covered by lifecycle configuration:
org.codehaus.mojo:buildnumber-maven-plugin:1.0:create-timestamp
(execution: generate-build-number, phase:
generate-sources) pom.xml /DataClient line 6 Maven Project
Does anyone know how to fix this problem? I tried several other ways which was listed in SO questions but it didn't worked.
I am using eclipse kepler and I do have pluginManagement as well in my pom.xml file.
My pom.xml snippet where I am using plugins:
<build>
<pluginManagement>
<plugins>
<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<argLine>-javaagent:"${settings.localRepository}"/com/googlecode/jmockit/jmockit/1.7/jmockit-1.7.jar</argLine>
</configuration>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>cobertura-maven-plugin</artifactId>
<configuration>
<instrumentation>
<excludes>
<exclude>**/test/**/*.class</exclude>
</excludes>
</instrumentation>
<formats>
<format>xml</format>
<format>html</format>
</formats>
</configuration>
</plugin>
<plugin>
<artifactId>maven-javadoc-plugin</artifactId>
<version>2.9.1</version>
<configuration>
<author>false</author>
<keywords>true</keywords>
<show>public</show>
<links>
<link>http://docs.guava-libraries.googlecode.com/git-history/v16.0/javadoc/</link>
<link>http://netty.io/4.0/api/</link>
</links>
<doctitle>Data Client API (${project.version})</doctitle>
<windowtitle>Data Client API (${project.version})</windowtitle>
<groups>
<group>
<title>Core API</title>
<packages>com.host.grads.client:com.host.grads.client.resources</packages>
</group>
<group>
<title>Miscellaneous</title>
<packages>com.host.grads.client.utils</packages>
</group>
</groups>
</configuration>
<executions>
<execution>
<id>attach-javadocs</id>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</pluginManagement>
</build>
I found this on SO and I think that it is the answer to your problem : Plugin execution not covered by lifecycle configuration (JBossas 7 EAR archetype)
I copy the text initially written by Jan :
This is a "feature" of the M2E plugin that had been introduced a while ago. It's not directly related to the JBoss EAR plugin but also happens with most other Maven plugins.
If you have a plugin execution defined in your pom (like the execution of maven-ear-plugin:generate-application-xml), you also need to add additional config information for M2E that tells M2E what to do when the build is run in Eclipse, e.g. should the plugin execution be ignored or executed by M2E, should it be also done for incremental builds, ... If that information is missing, M2E complains about it by showing the "Plugin execution not covered by lifecycle configuration" error message.
See here for a more detailed explanation and some sample config that needs to be added to the pom to make that error go away:
https://www.eclipse.org/m2e/documentation/m2e-execution-not-covered.html
If you need to implement this solution, you can have a look to this comment of the previously mentioned question : https://stackoverflow.com/a/26447353/4810148
Here is a copy of what coderplus answered. Of course you will have to replace the groupId and artifactId by the ones of the plugin that is concerned by your case.
Eclipse has got the concept of incremental builds.This is incredibly useful as it saves a lot of time.
How is this Useful
Say you just changed a single .java file. The incremental builders will be able to compile the code without having to recompile everything(which will take more time).
Now what's the problem with Maven Plugins
Most of the maven plugins aren't designed for incremental builds and hence it creates trouble for m2e. m2e doesn't know if the plugin goal is something which is crucial or if it is irrelevant. If it just executes every plugin when a single file changes, it's gonna take lots of time.
This is the reason why m2e relies on metadata information to figure out how the execution should be handled. m2e has come up with different options to provide this metadata information and the order of preference is as below(highest to lowest)
pom.xml file of the project
parent, grand-parent and so on pom.xml files
[m2e 1.2+] workspace preferences
installed m2e extensions
[m2e 1.1+] lifecycle mapping metadata provided by maven plugin
default lifecycle mapping metadata shipped with m2e
1,2 refers to specifying pluginManagement section in the tag of your pom file or any of it's parents. M2E reads this configuration to configure the project.Below snippet instructs m2e to ignore the jslint and compress goals of the yuicompressor-maven-plugin
<pluginManagement>
<plugins>
<!--This plugin's configuration is used to store Eclipse m2e settings
only. It has no influence on the Maven build itself. -->
<plugin>
<groupId>org.eclipse.m2e</groupId>
<artifactId>lifecycle-mapping</artifactId>
<version>1.0.0</version>
<configuration>
<lifecycleMappingMetadata>
<pluginExecutions>
<pluginExecution>
<pluginExecutionFilter>
<groupId>net.alchim31.maven</groupId>
<artifactId>yuicompressor-maven-plugin</artifactId>
<versionRange>[1.0,)</versionRange>
<goals>
<goal>compress</goal>
<goal>jslint</goal>
</goals>
</pluginExecutionFilter>
<action>
<ignore />
</action>
</pluginExecution>
</pluginExecutions>
</lifecycleMappingMetadata>
</configuration>
</plugin>
</plugins>
</pluginManagement>
3) In case you don't prefer polluting your pom file with this metadata, you can store this in an external XML file(option 3). Below is a sample mapping file which instructs m2e to ignore the jslint and compress goals of the yuicompressor-maven-plugin
<?xml version="1.0" encoding="UTF-8"?>
<lifecycleMappingMetadata>
<pluginExecutions>
<pluginExecution>
<pluginExecutionFilter>
<groupId>net.alchim31.maven</groupId>
<artifactId>yuicompressor-maven-plugin</artifactId>
<versionRange>[1.0,)</versionRange>
<goals>
<goal>compress</goal>
<goal>jslint</goal>
</goals>
</pluginExecutionFilter>
<action>
<ignore/>
</action>
</pluginExecution>
</pluginExecutions>
</lifecycleMappingMetadata>
4) In case you don't like any of these 3 options, you can use an m2e connector(extension) for the maven plugin.The connector will in turn provide the metadata to m2e. You can see an example of the metadata information within a connector at this link . You might have noticed that the metadata refers to a configurator. This simply means that m2e will delegate the responsibility to that particular java class supplied by the extension author.The configurator can configure the project(like say add additional source folders etc) and decide whether to execute the actual maven plugin during an incremental build(if not properly managed within the configurator, it can lead to endless project builds)
Refer these links for an example of the configuratior(link1,link2). So in case the plugin is something which can be managed via an external connector then you can install it. m2e maintains a list of such connectors contributed by other developers.This is known as the discovery catalog. m2e will prompt you to install a connector if you don't already have any lifecycle mapping metadata for the execution through any of the options(1-6) and the discovery catalog has got some extension which can manage the execution.
The below image shows how m2e prompts you to install the connector for the build-helper-maven-plugin.
.
5)m2e encourages the plugin authors to support incremental build and supply lifecycle mapping within the maven-plugin itself.This would mean that users won't have to use any additional lifecycle mappings or connectors.Some plugin authors have already implemented this
6) By default m2e holds the lifecycle mapping metadata for most of the commonly used plugins like the maven-compiler-plugin and many others.
Now back to the question :You can probably just provide an ignore life cycle mapping in 1, 2 or 3 for that specific goal which is creating trouble for you.
I just taken the project - I checkout this and I want to resolve all problems
one of the problems which I cannot to resolve
Error(s) found in manifest configuration (org.apache.felix:maven-bundle-plugin:2.3.7:bundle:default-bundle:package)
it refers to this row of pom.xml:
<plugin>
code around this row:
<build>
<plugins>
<plugin>
<groupId>com.squeakysand.jsp</groupId>
<artifactId>jsptld-maven-plugin</artifactId>
<configuration>
<shortName>ctc</shortName>
<processTagFiles>true</processTagFiles>
</configuration>
<executions>
<execution>
<goals>
<goal>generate</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>//this row
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<extensions>true</extensions>
<configuration>
<instructions>
<Include-Resource>
META-INF/${project.artifactId}-${project.version}.tld=${project.build.outputDirectory}/META-INF/${project.artifactId}-${project.version}.tld,
{maven-resources}
</Include-Resource>
<Sling-Bundle-Resources>
/META-INF/tags
</Sling-Bundle-Resources>
</instructions>
</configuration>
</plugin>
</plugins>
</build>
Please, help me resolve this problem.
Old question but for future Google results.
The issue is an old version of maven-bundle-plugin, specifically 2.3.7. Updating the pom.xml to use the latest (currently 2.5.0) fixed the issue.
Open the maven console (see the chapter "Enabling the Maven Console" here: http://www.theserverside.com/news/1363817/Introduction-to-m2eclipse).
Project right click->Maven->Update Project
You will see the real manifest problem in error messages in m2e console. Then you can fix them.
This error also occurs if the files referenced in the Include-Resource tag are not found by Eclipse. E.g. if the files are generated during the build process and Eclipse cannot execute one of the build steps (because of a missing m2e connector for instance). In this case check the build process and install required m2e connectors if available.
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>