I'm used to use mvn for compilation, packaging, and so on. Reading more carefully through the documentation, I learned that mvn takes as argument either a life cycle, a phase, or a goal. The documentation also states that there are three built-in life cycles, namely default, clean, and site.
I can run mvn clean and mvn site but I cannot run mvn default , I get the following error:
[ERROR] Unknown lifecycle phase "default". You must specify a valid
lifecycle phase or a goal ...
Am I missing something obvious? I read several documentations and can't find anyone mentioning that mvn default should not work, and why.
You cannot call mvn with a life cycle as argument.
You can either use a phase or a goal.
A phase belongs to a life cycle. Running something like mvn install with run the default life cycle up to (and including) the phase install.
Related
Can I execute a Maven phase (say: deploy) without implicitly calling the previous ones?
The reason: I would like to construct something like install site-deploy (only-deploy) to make sure that the deployment of the artifact only happens if all other phases/goals were successful. I cannot replace (only-deploy) with deploy:deploy because some projects which use this configuration have additional goals in the deploy phase.
No, it is called lifecycle for a reason. When we start with the next major release of Maven, we'll work on advanced lifecycle handling, where https://issues.apache.org/jira/browse/MNG-5666 is part of the solution for your issue.
Both the install and deploy plugin have an experimental xxxAtEnd, maven-site-plugin deploy goal should require such option as well.
It's (now) possible:
To run a specific goal without executing its entire phase (and the
preceding phases), we can use the command:
mvn <PLUGIN>:<GOAL>
For example, to run the integration-test goal from the Failsafe
plugin, we need to run:
mvn failsafe:integration-test
another example: mvn compiler:compile
I have yet to find documentation on what exactly triggers the force update and I've seen that it behaves differently depending on which lifecycle phase is run. This has led me to the conclusion though that maven certainly cares which phase you are running if you try to force update (with a -U) and ignores the force update if it doesn't need to.
I'd like to force an update even when I am not running a default lifecycle phase directly. My use case is in releasing my app with timestamped snapshot versions with the command:
mvn clean release:perform release:prepare -U
I'm seeing that even though the snapshots are versioned, internally it is getting the latest SNAPSHOT version in its local repo. If I run mvn compile -U first, then my snapshots are updated, and the release happens as expected.
I am curious as to why the timestamp version isn't used to pull the new artifact from nexus, but I figure it has something to do with the more narrow-minded release plugin rather than with maven itself.
Since I'm accepting defeat with the release-plugin, is there a way to force the update without running a separate (and unnecessary) lifecycle phase. Or a way to pass in the -U to be run by the maven release plugin when building my project?
First you are mixing different concepts. You are calling:
mvn release:prepare...
which does not start a life cycle in contradictions it runs the release plugin with it's particular goal prepare and of course .. release:perform runs the goal perform.
Furthermore the release plugin starts a sub process (starting maven in subfolder target/checkout) with the created release (tagged state) which usually does not transfer the -U option to this sub process. This can be accomplished by using `mvn -Darguments="..."'.
But if you like to force an update of snapshot's during your build you can simply using mvn -U... like:
mvn -U clean package
This means simple let maven checks in Nexus are there newer SNAPSHOT's if yes download them to local repository instead of waiting till time out for updating of SNAPSHOT's has come (see updatePolicy).
If you like to change your versions in your build without the maven-release-plugin you can take a look at the versions-maven-plugin but in this case you need to do your tagging etc. yourself.
First of all don't let release candidate ever dependent on SNAPSHOTS, if you still want to do it then
mvn dependency:resolve -U
What is the difference between the "mvn install" command, versus the use of the jar:jar plugin ?
Its clear that "install" seems to build a jar, and so, I am wondering what the need for the jar:jar plugin would be.
There are two types of things you can specify on the maven command line:
lifecycle phases (these do not include a : character)
plugin goals (these include at least one : character, depending on how fully you specify the plugin, it could be short-name:goal or groupId:artifactId:goal or groupId:artifactId:version:goal)
There are three lifecycles: default, clean and site. Each lifecycle consists of a series of phases. When you specify a phase in a lifecycle then Maven will execute in order all the phases in that lifecycle up to and including the specified phase.
When you specify a plugin goal then that plugin goal is invoked and only that plugin goal.
Maven has a concept of a packaging which defines a default set of plugin bindings to lifecycle phases. For example the jar packaging (which is default unless your pom.xml includes a <packaging>...</packaging> element) by default binds jar:jar to the package phase and binds install:install to the install phase.
So when you type
$ mvn package
Maven will run all the way through the lifecycle phases executing plugins that are bound (either from the lifecycle or by specifying plugin executions in the pom) as it goes along.
When you type
$ mvn jar:jar
Maven will just run the jar plugin's jar goal.
The lifecycle is 99 times out of 100 the one you want to use.
Here are the times you would typically want to invoke plugin goals directly
jetty:run to start a webapp server
surefire:test to quickly re-run the tests (usually with -Dtest=... to specify the specific one
release:prepare release:perform to release your code
versions:... to do some updating or querying of version related stuff, e.g. versions:display-plugin-updates
ship:ship or cargo:deployer-deploy to push (ship) your built artifacts to a hosting environment
mvn install command will "execute" the maven lifecycle up to the install phase.
It means that all previous phases will be executed (including the package phase).
On a simple maven jar project, the package phase is bind to the maven-jar-plugin. And so executing mvn install will execute at some point jar:jar.
install puts the artifact in your local (on your machine) maven repository, jar:jar does not. If you call jar:jar on a library then try to reference that library in another project, it will not be in your local repository.
Also note that mvn package is a cleaner way to do packaging, rather than using jar:jar.
I am using Maven multi module project. When I run maven and one of the modules fails I get the error messages and then the following line
After correcting the problems, you can resume the build with the command
mvn <goals> -rf :my.module.name
Does Maven hold any state? Is it possible to run
mvn <goal> `start from where we left off`
The reason I ask is that some of my module names are quite long. I can copy from the cmd prompt but I'd just like a quicker / shorter command. Often saving a couple of seconds may not seem much but over the course of my maven usage it could save me a lot.
The question is
does maven hold state?
if so can I quickly rerun from where I left off?
Thanks
You can use Maven Shell to execute maven goals/phases in a pre-loaded shell environment, significantly reducing the build time.
No, but you could go into the individual modules and build them - this is in essence what maven does, you just need to go through them in the correct order otherwise you might get confusing results (i.e old dependent-module builds etc). The reactor build summary shows you the module build order that maven will run through and is displayed at the start of the build.
In the end though you will always need to do a full build from the parent module in order to build your final artifact. And it's often easiest just to run from the top anyway.
No - at least in my experience, Maven does not hold its state. This is especially important if you are running mvn package. Whereas running mvn package on a multi-module project will work fine (all modules will be able to use the produced artifact of a previous module), if the build is interrupted, resuming from your build mid-way will cause artifact not found errors when referring to previously successfully built modules.
Two ways around this. Rebuild everything, or use mvn install to require maven to install to your local repo (if you are not ready to deploy). In such a case, resuming your build will not fail as it will find the previously built modules in your local repo.
Just as a personal pet peeve, you need to know the module artifact name when using the -rf flag. Maven will show you the display name, which may or may not be the artifact name. -rf requires the artifact name.
I'm trying to set up a Maven project so that it will build upon receiving the mvn command at the command line without any target such as install or package.
This might seem a strange goal, but I'm guessing that it is the simplest way to fit a new project into an existing architecture.
I've been looking at some old pom.xml files, in an effort to find how this is being defined, with no luck so far. (And too much is different for me to simply copy an old pom.)
I believe you're looking for the <defaultGoal> element. It's part of the BaseBuild Element Set.
The value of the <defaultGoal> element can be either a goal or a life-cycle phase. So for example, if I add this to my pom:
<build>
<defaultGoal>package</defaultGoal>
</build>
Then I can invoke the mvn command with no arguments and the life-cycle as far as the package phase will be run (as if I had invoked mvn package).