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
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
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
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
Hi,
This is related to what's called the maven super-pom.
There was a time where Maven (prior to 2.1.0 I seem to remember) would
always try and find the latest version for every plugins. This was very bad
because it made the build unreproducible even if you didn't change the maven
version you
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,
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
asgroupId:artifactId:version:goal, seems to be the two choices to
configure
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
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:
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
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
Envoyé de mon VT100 Phone
Le 25 sept. 2011 à 14:27, Baptiste MATHUS m...@batmat.net a écrit :
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
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:
Every corporate pom is unique, so it's quite hard to talk about THE corporate
pom.
A corporate pom might contain things like
- licenses (or is this specified per project?)
- distributionManagement
- mailing lists
- organization
And it might contain predefined versions for plugins bound to
Hi,
I thought you were being ironic in your previous message. My answer was
using the same kind of wording.
I might have misread you though, if so please excuse me.
A corporate is nothing more than a POM that every projects of a company
would inherit. It could be listed more visibly in some
It turns out jvmSetings is correct element to use but It must be
inside daemon configuration.
Your doc changes to https://jira.codehaus.org/browse/MAPPASM-127 is wrong
Thanks for leading me to right direction
-Dan
On Sat, Sep 24, 2011 at 9:02 PM, Deng Ching och...@apache.org wrote:
Hi Dan,
Aha ... which then cause it to be located in the file
META-INF\plexus\artifact-handlers.xml in the JAR
%M2%\libs\maven-core-3.0.3.jar
Thanks! That answers the last question.
Beside this, a pluginManagement-section in an own common parent-pom (for
the company, organization etc.) seems to be a
Ok, I'll re-open the issue and update it. Thanks for pointing that out :)
-Deng
On Mon, Sep 26, 2011 at 4:10 AM, Dan Tran dant...@gmail.com wrote:
It turns out jvmSetings is correct element to use but It must be
inside daemon configuration.
Your doc changes to
Hi,
I have a hibernate project.My source files are located inside the package
com.sdp.So I have kept the hiberbnate.cfg.xml file in the same level where
com folder is located.Now I have created a maven quickstart artifact.Inside
src main java I have copied my com folder.Now where to keep
18 matches
Mail list logo
