I'm sorry to be so ignorant. Exactly how would I go about setting up a
corporate super pom and where is it documented?
I have looked on the Maven website and in the Maven Complete Reference
and I have not noticed any explanation of this capability.
On 9/25/11 8:27 AM, Baptiste MATHUS wrote:
And what would be the benefit of storing that information over using a
corporate super-pom, which is the way to go to define corporate-wide
versions to be used?
I don't think having things outside the build context is a good idea.
Settings.xml is necessary, but it should stay as small as possible IMO, that
is: basically almost only contain the corporate mrm address.
Storing plugin versions outside the project itself would create a whirlwind
of unreproducible issues, which were typical before maven 2.0.9.
Cheers
2011/9/25 Andy Glick<andygl...@gmail.com>
Robert,
I believe that you have explained that the super pom or some important
aspects of it reside in artifact-handlers.xml and that if I were to modify
it and build a new version of Maven that I would have modified the super pom
and universally changed the version of a plugin available from the command
line without a pom in a manner that would be both controlled and repeatable?
That is useful information, I appreciate the suggestion. Though it does
seem to me that this information is quite valuable and ought to be more
widely disseminated.
Is it possible that this file, or some parts of it, could be exposed as a
public resource and available for configuration similar to settings.xml?
On 9/25/11 5:38 AM, Robert Scholte wrote:
That should be http://svn.apache.org/viewvc/**
maven/maven-3/tags/maven-3.0.**3/maven-core/src/main/**
resources/META-INF/plexus/**artifact-handlers.xml?view=log<http://svn.apache.org/viewvc/maven/maven-3/tags/maven-3.0.3/maven-core/src/main/resources/META-INF/plexus/artifact-handlers.xml?view=log>
And here you see that the maven-deploy-plugin uses version 2.5
-Robert
Date: Sun, 25 Sep 2011 11:32:03 +0200
From: pr...@jonand.se
To: users@maven.apache.org
Subject: Re: Can I configure the version used as default for Maven
plugins?
"To get what you want, just put a minimal pom.xml into the directory from
which you invoke your mvn goal and use pluginMgmt to bump the version"
Thanks. This and the tip from Kristian, that the goal always is invoked
as<groupId>:<artifactId>:<**version>:<goal>, seems to be the two choices
to configure the plugin version used and of them seems use of the qualified
name then often be the easiest choice.
I understand the reason to why the default version of the plugins used
not is just updated every time, that seems wise, and as I understand it is
it in the pluginManagement of the super pom where the default version of
plugins with a prefix is configured. Just because I am a bit curious did I
also have a look at the super pom which I found should be located in the
file org/apache/maven/model/pom-4.**0.0.xm in the JAR
lib/maven-model-builder-3.0.3.**jar but I didn't find the configured
plugin versions there. Now it is only about curiosity : ) but where do I
find this configuration?
Anyway, thanks for good information! It is interesting to learn these
details about Maven to better understand how it works.
Jonny Andersson
2011-09-25 10:35, Stephen Connolly wrote:
The best practice for poms is to always specify a version of plugins.
before Maven 2.0.8 the plugins used in the standard lifecycle did not
have their version specified in the superpom that is baked into Maven
itself.
This meant that if a plugin was updated and cause a breakage for
people, _everyone_ had the pain until they set the version explicitly.
So from 2.0.9 onwards, Maven has included baked in versions for the
plugins invoked by the baked in packaging's lifecycles.
Every time there is a release of Maven, we typically bump up the
versions to the next version that we think is stable.
3.0.x now has baked in warnings that you should specify the plugin
version in your pom, that is so that at some stage, think 3.1.x or
maybe 4.0.x we can remove the baked in versions _hack_ that was
necessary to allow us to release versions of some critical core
plugins (such as m-compiler-p) without fear of causing major issues
for people who had not baked the version into their pom.
The side-effect of all this is that if you are execution mvn plugin
goals directly from the cli in a directory that does not have a
pom.xml and you want to use a newer version, you need to call out the
full long form of the plugin.
To get what you want, just put a minimal pom.xml into the directory
from which you invoke your mvn goal and use pluginMgmt to bump the
version
-Stephen
On 25 September 2011 09:12, Jonny Andersson<pr...@jonand.se> wrote:
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<pr...@jonand.se>
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<andygl...@gmail.com>
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:
users-unsubscribe@maven.**apache.org<users-unsubscr...@maven.apache.org>
For additional commands, e-mail: users-h...@maven.apache.org
------------------------------**------------------------------**
---------
To unsubscribe, e-mail:
users-unsubscribe@maven.**apache.org<users-unsubscr...@maven.apache.org>
For additional commands, e-mail: users-h...@maven.apache.org
------------------------------**------------------------------**
---------
To unsubscribe, e-mail:
users-unsubscribe@maven.**apache.org<users-unsubscr...@maven.apache.org>
For additional commands, e-mail: users-h...@maven.apache.org
------------------------------**------------------------------**
---------
To unsubscribe, e-mail:
users-unsubscribe@maven.**apache.org<users-unsubscr...@maven.apache.org>
For additional commands, e-mail: users-h...@maven.apache.org
------------------------------**------------------------------**
---------
To unsubscribe, e-mail:
users-unsubscribe@maven.**apache.org<users-unsubscr...@maven.apache.org>
For additional commands, e-mail: users-h...@maven.apache.org
------------------------------**------------------------------**---------
To unsubscribe, e-mail:
users-unsubscribe@maven.**apache.org<users-unsubscr...@maven.apache.org>
For additional commands, e-mail: users-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
