I don't know if this is the answer or not but it might lead you in the right direction...
The command install:install
is actually a goal on the maven-install-plugin. This is different than the install
maven lifecycle phase.
Maven lifecycle phases are steps in a build which certain plugins can bind themselves to. Many different goals from different plugins may execute when you invoke a single lifecycle phase.
What this boils down to is the command...
mvn clean install
is different from...
mvn clean install:install
The former will run all goals in every cycle leading up to and including the install (like compile, package, test, etc.). The latter will not even compile or package your code, it will just run that one goal. This kinda makes sense, looking at the exception; it talks about:
StarTeamCollisionUtil: The packaging for this project did not assign a file to the build artifact
Try the former and your error might just go away!
TL;DR To fix this issue, invoke packaging plugin before, e.g. for jar
packaging use maven-jar-plugin
, as following:
mvn jar:jar install:install
Or
mvn jar:jar deploy:deploy
If you actually needed to deploy.
Gotcha This approach won't work if you have multi-module project with different packagings (ear/war/jar/zip) – even worse, wrong artifacts will be installed/deployed! In such case use reactor options to only build the deployable module (e.g. the war
).
Explanation
In some cases you actually want to run directly a install:install
or deploy:deploy
goal (that is, from the maven-deploy-plugin
, the deploy
goal, not the Maven deploy
phase) and you would end up in the annoying The packaging for this project did not assign a file to the build artifact
.
A classic example is a CI job (a Jenkins or Bamboo job, e.g.) where in different steps you want to execute/care about different aspects:
mvn clean install
, performing tests and test coveragemvn sonar:sonar
plus further optionsmvn deploy
, because it would again execute previous phases (and compile, test, etc.) and you want your build to be effective but yet fast.Yes, you could speed up this last step at least skipping tests (compilation and execution, via -Dmaven.test.skip=true
) or play with a particular profile (to skip as many plugins as possible), but it is much easier and clear to simply run mvn deploy:deploy
then.
But it would fail with the error above, because as also specified by the plugin FAQ:
During the packaging-phase all gathered and placed in context. With this mechanism Maven can ensure that the
maven-install-plugin
andmaven-deploy-plugin
are copying/uploading the same set of files. So when you only executedeploy:deploy
, then there are no files put in the context and there is nothing to deploy.
Indeed, the deploy:deploy
needs some runtime information placed in the build context by previous phases (or previous plugins/goals executions).
It has also reported as a potential bug: MDEPLOY-158
: deploy:deploy does not work for only Deploying artifact to Maven Remote repo
But then rejected as not a problem.
The deployAtEnd
configuration option of the maven-deploy-plugin
won't help neither in certain scenarios because we have intermediate job steps to execute:
Whether every project should be deployed during its own deploy-phase or at the end of the multimodule build. If set to
true
and the build fails, none of the reactor projects is deployed. (experimental)
So, how to fix it?
Simply run the following in such a similar third/last step:
mvn jar:jar deploy:deploy
The maven-jar-plugin
will not re-create any jar as part of your build, thanks to its forceCreation
option set to false
by default:
Require the jar plugin to build a new JAR even if none of the contents appear to have changed. By default, this plugin looks to see if the output jar exists and inputs have not changed. If these conditions are true, the plugin skips creation of the jar.
But it will nicely populate the build context for us and make deploy:deploy
happy. No tests to skip, no profiles to add. Just what you need: speed.
Additional note: if you are using the build-helper-maven-plugin
, buildnumber-maven-plugin
or any other similar plugin to generate meta-data later on used by the maven-jar-plugin
(e.g. entries for the Manifest file), you most probably have executions linked to the validate
phase and you still want to have them during the jar:jar
build step (and yet keep a fast execution). In this case the almost harmless overhead is to invoke the validate
phase as following:
mvn validate jar:jar deploy:deploy
Yet another additional note: if you have not jar
but, say, war
packaging, use war:war
before install/deploy instead.
Gotcha as pointed out above, check behavior in multi module projects.
This reply is on a very old question to help others facing this issue.
I face this failed error while I were working on my Java
project using IntelliJ IDEA
IDE.
Failed to execute goal org.apache.maven.plugins:maven-install-plugin:2.4:install (default-cli) on project getpassword: The packaging for this project did not assign a file to the build artifact
this failed happens, when I choose install:install
under Plugins - install
, as pointed with red arrow in below image.
Once I run the selected install
under Lifecycle
as illustrated above, the issue gone, and my maven install compile build successfully.
I have same issue. Error message for me is not complete. But in my case, I've added generation jar with sources. By placing this code in pom.xml:
<build>
<pluginManagement>
<plugins>
<plugin>
<artifactId>maven-source-plugin</artifactId>
<version>2.1.2</version>
<executions>
<execution>
<phase>deploy</phase>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</pluginManagement>
</build>
So in deploy phase I execute source:jar goal which produces jar with sources. And deploy ends with BUILD SUCCESS
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With