But it still seems strange to me that <prefix>:<goal> for the maven-deploy-plugin always gives me version 2.5 (for Maven 3.0.3) and not the newest available version 2.7. I also tried to delete version 2.5 from my local repo one time with version 2.7 left and tried again which caused version 2.5 to be downloaded. What makes me confused is that I don't understand where Maven 3.0.3 looks to see that it is version 2.5 that should be used every time. I have not tried but I guess this same version would be used when invoked as part of a pom if not set explicitly.

Jonny Andersson

On 2011-09-25 10:05, kristian wrote:
from the command-line without a pom.xml - yes you need to use the full
plugin name
<groupId>:<artifactId>:<version>:<goal>

- Kristian

On Sun, Sep 25, 2011 at 1:25 PM, Jonny Andersson<[email protected]>  wrote:
I just remembered something I have read a while ago in "Maven: The complete
reference" from Sonatype which partly answers my question ... The file
~/.m2/repository/org/apache/maven/plugins/maven-metadata-central.xml is
where the prefix deploy is bound to maven-deploy-plugin and this could
bypassed with the explicit name of the plugin wanted like
org.apache.maven.plugins:maven-deploy-plugin. Of some reason is the group id
not included in the prefix mapping and definitely not the version so it does
not fully answer my question. well, a workaround is of course to always use
the qualified name of the plugin with the version included when it is
invoked from the command line.

Jonny Andersson

On 2011-09-25 09:32, Jonny Andersson wrote:
Thanks for your information. Use of pluginManagement in a parent pom to
gain control over which plugins that are used seems to be a good advice. But
I can't see how it could give control over which version of a plugin that is
used when the goal for the plugin is invoked from the command line like the
command mvn deploy:deploy-file ... But there seems to be somewhere
configuration that decides that the default version used for that command
should be 2.5, not the newest available version in the central repository,
2.7.

Jonny Andersson

On 2011-09-25 06:31, kristian wrote:
have a look at how it is done via

mvn help:effective-pom

- Kristian

On Sat, Sep 24, 2011 at 4:54 PM, Andy Glick<[email protected]>    wrote:
You would normally do this by using a pluginManagement tag in your pom
and
in that context declaring the plugin and setting the version to 2.7.
This is
particularly useful in a parent pom because the version will be
inherited by
all child poms. Then you would not include the version tag in the plugin
declaration in the plugins tag.

I think that it may be possible to configure this in a site super pom.

On 9/24/11 6:22 AM, Jonny Andersson wrote:
Hi!

I have a question that I guess already have been asked somewhere but I
have not been able to find the answer myself. The question came up when
I
ran the command mvn deploy:deploy-file on the command line and found
that
the arg sources (given as -Dsources=...) wasn't recognized. It turned
out
that the command mvn deploy:deploy file always resolves to version 2.5

mvn org.apache.maven.plugins:maven-deploy-plugin:2.5:deploy-file

where I would like it to resolve to resolve to version 2.7

org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy-file

as that version have the sources arg as an option so the question is,
is
it possible to configure which version of the plugin the unqualified
commands for a plugin like mvn deploy:deploy-file should resolve to?

I use Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100) in Win XP with
java
1.6.0

Thanks for any information about this!

Jonny Andersson

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]



---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]



Reply via email to