The following line should be added to the defaultAliases map of ExecuteCliMojo:

put("testResources", "org.apache.maven.plugins:maven-resources-plugin:testResources");

As a workaround, you can just spell out the command:

org.apache.maven.plugins:maven-resources-plugin:testResources

Please note that 0.6.3.CR2 is a version hosted at the JBoss Maven repository from my fork: http://github.com/mojavelinux/maven-cli-plugin/tree

Are you having a problem with execute or execute-phase? I'm pretty sure properties work in execute-phase.

You can verify by running the following in the console:

org.apache.maven.plugins:maven-help-plugin:evaluate

Then you have to type an expression, such as ${myproperty}. You'll have to deal with the lack of echo (what you type won't be shown), the press enter. The value will be outputted.

Hello,
It's with the execute-phase, still on 0.6.3.CR2 (should I use another version and deploy it into our own maven repositories) ?
The error with properties happens with already defined properties, they cannot be overridden.
To reproduce:
- define a "prop" property with value "oldvalue" in your pom - test1:

mvn cli:execute-phase -Dprop=newvalue
org.apache.maven.plugins:maven-help-plugin:evaluate gives "oldvalue"

• test2: mvn cli:execute-phase org.apache.maven.plugins:maven-help-plugin:evaluate -Dprop=newvalue gives "oldvalue" Thanks,

Ah, so that is the error report. That you cannot override properties, not that they don't work. I think this may actually be a problem in Maven, but don't hold me to that.

Sorry for title, that was what I meant by "user properties" versus "properties defined by default" (i just updated this issue title).
I don't have this issue with maven, the same properties are correctly overridden from command line. Do you mean the new properties' values are evaluated at a moment in maven execution process that your plugin cannot use ?
I effectively saw a lot of maven bugs about properties some years ago, do you rely on old maven api ?

It does use the Maven Embedder which by chance has some legacy issues. It could be a simple as just not adding the property correctly in the command line parser. I'll dig into it. I'm sure we can get it fixed up. Thanks for reporting this.

I did some digging. This appears to be an error deep down in Maven 2.0.x. Basically, when you run the following code:

session.getExecutionProperties().putAll(commandCall.getProperties());
project.getProperties().putAll(commandCall.getProperties());
MavenExecutionRequest request = new DefaultMavenExecutionRequest(

 session.getLocalRepository(), session.getSettings(),
 session.getEventDispatcher(),
 commandCall.getCommands(), userDir.getPath(),
 profileManager, session.getExecutionProperties(),
 project.getProperties(), true);

Properties props = ((DefaultMaven) embeddedMaven).getProject(new File("pom.xml"), request).getProperties();

The properties returned are those in the pom.xml. The properties assigned to the request object, either userProperties or session executionProperties do not override the values from the pom.xml. What's interesting is that the profile manager does see the properties, so the properties specified using -D can activate a profile.

I'm not sure how to fix this. Following Maven through its labyrinth gets really hairy...but at least we know what we are looking for. The return value of getProject() (which is deep inside of execute()), must show the properties as overridden. Otherwise, it won't work.

I am now 100% sure this is a bug in Maven 2.0 (specifically tested with 2.0.8 - 2.0.10). It has been resolved in Maven 2.1. I verified I can run this plugin under 2.1 (with a slight hack I mention elsewhere) and the properties can be overridden. So unfortunately, there is nothing the plugin can do to solve the problem in Maven 2.0.

Understood. What a pity our project are not compatible with Maven 2.1 for now. Congratulations and many thanks for your deep inspection into Maven labyrinth code. Maybe they could do some backport to fix this issue on 2.0. For now, I'll have to manage properties with profiles in order to use your nice plugin until we're able to use Maven 2.1. Thanks again.

Btw, the list of possible life-cycle goals is already a constant. It's just a matter of adding the cross-reference (and regex for plugin goals).