Is it possible to force any maven plugin to execute with VM arguments when I do mvn clean install?
More context
I have an old project that I try to mirgate to java 11. During this migration I had trouble with wadl-client-plugin and JAXB showing this error.
schema_reference: Failed to read schema document '...', because 'file' access is not allowed due to restriction set by the accessExternalSchema property.
When I run it like mvn clean install -Djavax.xml.accessExternalSchema=all it works. I need to include somehow -Djavax.xml.accessExternalSchema=all to the plugin execution when I run mvn clean install. I've checked wadl-client-plugin's docs and don't see anything about it. Is it possible to do it somehow in general way? Configuring local JVM is not an option neither as I cannot do it at all machines.
I finally found an answer here
properties-maven-plugin inside my pom did the trick.
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>properties-maven-plugin</artifactId>
<version>1.0.0</version>
<executions>
<execution>
<id>set-additional-system-properties</id>
<goals>
<goal>set-system-properties</goal>
</goals>
</execution>
</executions>
<configuration>
<properties>
<property>
<name>javax.xml.accessExternalSchema</name>
<value>all</value>
</property>
</properties>
<outputFile/>
</configuration>
</plugin>
I try to put my app in production mode, I'm on vaadin flow 14.1.5, the profile is already on the pom.xml.
production profile on the pom.xml is like this:
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<configuration>
<jvmArguments>-Dvaadin.productionMode</jvmArguments>
</configuration>
</plugin>
<plugin>
<groupId>com.vaadin</groupId>
<artifactId>vaadin-maven-plugin</artifactId>
<version>${vaadin.version}</version>
<executions>
<execution>
<goals>
<goal>prepare-frontend</goal>
<goal>build-frontend</goal>
</goals>
<phase>compile</phase>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
However when running on the terminal: mvn clean package -P production
I got this:
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 6.437 s
[INFO] Finished at: 2020-04-25T00:22:09-04:00
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal com.vaadin:vaadin-maven-plugin:14.1.5:build-frontend (default) on project project-maya: Execution default of goal com.vaadin:vaadin-maven-plugin:14.1.5:build-frontend failed: Unsupported class file major version 58 -> [Help 1]
I'm on testing at the moment so I don't really care about running on development mode but I will be running on production mode soon and I really don't know what to do to fix this.
Edit: Vaadin 14.1.26 has now been released, which includes the fix for not being able to build with Java 14 (Flow issue #7918).
This is most likely an issue with Java 14.
There's a fix in Flow version 2.1.9 and 2.2.0.beta2.
Vaadin 14.1.25 still uses 2.1.8, hopefully there will be a new version with 2.1.9 soon.
Vaadin 14.2.0.beta1 uses 2.2.0.beta2, so if you want you could try that.
Hopefully the fix is available in a stable release once you need production mode to work.
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 am having a problem with some functionality I need configured.
Here is a part of my POM, where I configured a project to be assembled into two different files: FirstNameProject-VERSION-bin.zip and SecondNameProject-VERSION-bin.zip.
The idea is that I had to maintain those names set, even if the original artefact is common.
<?xml version="1.0" encoding="UTF-8"?>
http://maven.apache.org/xsd/maven-4.0.0.xsd">
4.0.0
<groupId>com.project.my</groupId>
<artifactId>MyGenericProject</artifactId>
<name>Generic Project</name>
<version>2.0.2-SNAPSHOT</version>
...
<build>
<plugins>
....
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<version>2.2.1</version>
<executions>
<execution>
<id>first</id>
<configuration>
<finalName>FirstNameProject-${project.version}-bin</finalName>
<appendAssemblyId>false</appendAssemblyId>
<descriptors>
<descriptor>src/main/assembly/resources_first.xml</descriptor>
</descriptors>
</configuration>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
</execution>
<execution>
<id>second</id>
<configuration>
<finalName>FirstNameProject-${project.version}-bin</finalName>
<appendAssemblyId>false</appendAssemblyId>
<descriptors>
<descriptor>src/main/assembly/resources_second.xml</descriptor>
</descriptors>
</configuration>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
This is working properly and in the mvn package logs I can see:
[INFO] --- maven-assembly-plugin:2.2.1:single (first) # MyGenericProject ---
[INFO] Reading assembly descriptor: src/main/assembly/resources_first.xml
[INFO] Building zip: C:\MyPath\MyProject_trunk\target\FirstNameProject-2 .0.2-bin.zip
[INFO]
[INFO] --- maven-assembly-plugin:2.2.1:single (second) # MyGenericProject ---
[INFO] Reading assembly descriptor: src/main/assembly/resources_second.xml
[INFO] Building zip: C:\MyPath\MyProject_trunk\target\SecondNameProject-2.0 .2-bin.zip
The problem is that, at during install, it just reverts to the generic name and install the the rightly named file as the Generic one!
[INFO] --- maven-install-plugin:2.3.1:install (default-install) # MyGenericProject ---
[INFO] Installing C:\MyPath\MyProject_trunk\target\MyGenericProject-2.0.2-SNAPSHOT.jar to C:.m2\repository\com\project\my\MyGenericProject\2.0.2-SNAPSHOT\MyGenericProject-2.0.2-SNAPSHOT.jar
[INFO] Installing C:\MyPath\MyProject_trunk\pom.xml to C:.m2\repository\com\project\my\MyGenericProject\2.0.2-SNAPSHOT\MyGenericProject-2.0.2-SNAPSHOT.pom
[INFO] Installing C:\MyPath\MyProject_trunk\target\FirstNameProject-2.0.2-SNAPSHOT-bin.zip to C:.m2\repository\com\project\my\MyGenericProject\2.0.2-SNAPSHOT\MyGenericProject-2.0.2-SNAPSHOT.zip
I am imagining that this is because the install plugin has no visibility on exactly how the assembly plugin was configured so I ask you: how can I configure the install plugin so that I will end up with FirstNameProject-VERSION-bin.zip and SecondNameProject-VERSION-bin.zip installed in my repository??
I hope I was clear enough,
Thanks
It sounds like Maven is "attaching" the assembly artifact to the project under the default name. The first option is to scour the assembly plugin configuration to see if there's a way to control this. Looking through it myself, I don't see a way to do this. I would have thought it would have used your final name configuration, but if it doesn't, it doesn't.
The workaround I can offer, and I would hope someone can offer something more standard, is to configure the assembly to NOT attach itself.
Next, take the file it creates, the one with the name you want, and use the build-helper plugin to attach the file under the precise coordinates that you want.
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>