[ERROR] Unknown lifecycle phase "run". You must specify a valid lifecycle phase
or a goal in the format
I think you are using 'run' which maven is not able to recognize.
Use clean installonly
I got it resolved
Root Cause : The phases of the life cycle was not properly defined in execution tag in POM File results throwing the Error :
[ERROR] Unknown lifecycle phase "run". You must specify a valid lifecycle phase or a goal in the format
Related
i'm wondering about how Maven maps a phase to a lifecycle.
For example when running
mvn clean
then Maven executes the phases "pre-clean" and "clean" of the "clean" lifecycle.
But how does Maven determine that the phase "clean" (as provided as command line argument) belongs to the "clean" lifecycle? There could be another lifecycle that also has a "clean" phase.
It may be a rule that all phases over all lifecycles must have a unique name. But i don't know.
In Maven there existing only the following three life cycles
clean
default
site
The details are defined in the lifecycle binding of Maven core https://maven.apache.org/ref/3.8.1/maven-core/lifecycles.html
The existing and defined life cycles are defined in the following file:
META-INF/plexus/components.xml
AFAIK, you can create a custom build lifecycle in maven.
Also, AFAIK, you cannot tell maven to execute a lifecycle. You can either:
Tell maven to execute a phase: In this case, maven finds in which lifecycle this phase is, and then executes all phases in that lifecycle, up to the phase specified.
Tell maven to execute a goal, by specifying it as mvn plugin_name:goal_name
So, assume that I have created a custom lifecycle. And assume that this custom lifecycle has a phase named install.
When I write mvn install, will maven execute the default lifecycle (which has a phase named install) or my custom lifecycle (which also has a phase named install)?
How will maven determine which lifecycle to follow?
This is not supported (yet), though recently Stephen started a thread about it: http://maven.markmail.org/thread/z57dzgunecgfcrf7
Running $ mvn help:describe -Dcmd=clean tells you that 'clean' is a lifecycle, and lists its phases. Similarly $ mvn help:describe -Dcmd=site tells you that 'site' is a lifecycle and lists its phases.
Is there any value for the cmd parameter of the help:describe goal that will list the phases of the default lifecycle?
The cmd option is "a single goal or a single phase" to describe.
While it is true that clean and site are the name of lifecycles, they are also the name of phases within those lifecycles.
It also looks like the description the help:describe goal prints out is a bit misleading (here's the source code). cmd is not actually "a lifecycle with the following phases", but the name of a particular phase within a lifecycle whose phases are listed. You can prove this by trying mvn help:describe -Dcmd=post-site for example, and Maven prints out
'post-site' is a lifecycle with the following phases:
* pre-site: Not defined
* site: org.apache.maven.plugins:maven-site-plugin:3.0:site
* post-site: Not defined
* site-deploy: org.apache.maven.plugins:maven-site-plugin:3.0:deploy
even though 'post-site' is the name of a phase and not a lifecycle.
As for printing out the phases of the default lifecycle, just set cmd to the name of any phase within the default lifecycle, such as package or install and it will print them out.
Just to be complete, the definitions for all the standard phases and lifecycles are in Maven's components.xml and the the ID of the default lifecycle is 'default'.
Could you give me a detail explanation about the difference between jar and jar-no-fork goal?
I see it from official site, but I can not get a clear idea for this.
My interpretation: the jar goal is meant to be run from the command line (mvn source:jar), the jar-no-fork is meant to be bound to the lifecycle.
If you look at the docs for the jar goal the key phrase is "Invokes the execution of the lifecycle phase generate-sources prior to executing itself." If you configure your POM to run the source:jar goal as part of the lifecycle, Maven will re-run all of the goals bound to generate-sources and its predecessors. If you have many plugin goals bound to the validate or initialize phases all of those will run twice, lengthening the time of your build.
In contrast, jar-no-fork is what you attach to the build lifecycle because it expects to be bound to a phase somewhere after generate-sources and will not run the bound goals again.
I have verified this behavior by running Maven 3 with -X and reviewing the plugin executions that run.
I'm working my way through learning a somewhat complicated maven build. I've found a module that is using a bogus packaging type, "custom-war" to be specific. If I execute:
mvn -e -X clean install
maven complains thus:
[DEBUG] Error looking up lifecycle mapping to retrieve optional mojos. Lifecycle
ID: clean. Error: Component descriptor cannot be found in the component repository:
org.apache.maven.lifecycle.mapping.LifecycleMappingcustom-war.
However, it appears to go ahead and execute clean:clean, so it must have made some decisions on which goals to map to the lifecycle phases. Can anyone provide some insight into the decision making of maven in the face of a bogus packaging type?
I think I should add that this custom module appears to be "defining it's own default lifecycle bindings"; I've found a component.xml file that defines goal bindings for phases of the default lifecycle. In the light of this, the error appears to be complaining that there are no bindings declared for clean, but the format of the component.xml doesn't appear to support that.
The clean phase runs through to completion because the goals that are bound to this phase are independent of the packaging.
What should be done in response to the command mvn install on the other hand is predicated on the packaging. Maven encountered an unknown packaging of "custom-war" and so it threw its hands up.
See correlation of phases to packaging at Maven.