Re: pluginManagement questions
not exactly: the question is not about parent and childs, but about pluginManagement injection into build plugins, which works exactly like dependencyManagement injection into dependencies if you define a precise version in the build plugins (or in a dependency), dependencyManagement does not change it: defining a version is a way to override pluginManagement. Then the problem here is that parent pom should not have defined a version in build/plugins: this is a good practice exactly because it causes the problem you're facing: you cannot upgrade the version in child pluginManagement. The parent pom should be fixed, so you can define a new version in pluginManagement Regards, Hervé notice: the reference documentation is here [1] http://maven.apache.org/ref/3.1.1/maven-model-builder/ Le jeudi 14 novembre 2013 16:20:19 Laird Nelson a écrit : Suppose I have a parent pom that makes use of the maven-enforcer-plugin. As a matter of fact I do, and it's public, so you can follow along at home: parent groupIdorg.sonatype.oss/groupId artifactIdoss-parent/artifactId version7/version /parent Looking at that pom, there is this snippet in it: build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-enforcer-plugin/artifactId version1.0/version So it declares this as a plugin that it uses internally, and says it is going to use version 1.0. I understand that. I also understand that this plugin definition is inherited. If I do nothing else, and make use of the maven-enforcer-plugin, and do not specify a version, I'll get 1.0. Suppose now *my* pom--the first generation child--wants to enforce that throughout its world maven-enforcer-plugin version 1.3.1 should be used. My naive assumption was, oh, that's what pluginManagement is for. So I put this in: build pluginManagement plugins plugin artifactIdmaven-enforcer-plugin/artifactId version1.3.1/version And it's my understanding that second and greater generation children will be forced to use version 1.3.1 as a result of that. (If I have a child that inherits from THIS pom, then he'll use version 1.3.1.) However, I notice that while building THIS pom the oss-parent pom is still running maven-enforcer-plugin 1.0. It runs the maven-enforcer-plugin during the clean lifecycle, and so when I run mvn clean from my first generation child, I get version 1.0. This makes a certain amount of sense--my plugin management section probably shouldn't affect what versions my parent has chosen. On a whim, I *also* added a plugins section *in addition* to my pluginManagement section: build plugins plugin artifactIdmaven-enforcer-plugin/artifactId version1.3.1/version ...and ran again. This time maven-enforcer-plugin version 1.3.1 was run. I had to digest this for a while. Obviously my pluginManagement stanza is not in effect--we proved that already. So my first generation child pom can cause its parent pom to use a different version of the plugin by specifying a new version in the plugins stanza. Is that a good thing? An expected thing? On another whim I upped the version here to something enormous and nonsensical to really make sure I was seeing what I was seeing: version12/version ...and ran again. This time--with a pluginManagement section specifying version 1.3.1 and a parent pom specifying version 1.0 and my own pom specifying version 12--Maven tried to download version 12, which of course as of this writing does not exist. From all this I have gleaned the following information, and I'm hoping someone can tell me where I'm wrong (I'm sure I'm wrong somewhere): * pluginManagement constrains versions for children, should they happen to make use of the plugins mentioned therein. That's all it does. * Without children, there is no point in putting in a pluginManagement stanza. * pluginManagement doesn't constrain its sibling plugins stanza, nor does it constrain anything about its parent, nor does it constrain anything inherited from the parent. * Specifically, if you have a buildplugins stanza **and** a buildpluginManagement stanza, and they declare the same plugin but different versions, then the buildpluginsversion element will trump everything else *in that pom* (not in his children), including any plugin declarations from the parent. * The versions-maven-plugin's display-plugin-updates goal will tell you that everything is up to date and fine if you have a pluginManagement stanza and no plugins section--but as I've already written above your first-generation child pom may end up using an older version of a plugin anyway, because his parent might have defined it. Even though your pluginManagement stanza declares the proper, up-to-date version, that version may not be respected if your parent has a buildplugins stanza that
[ANN] Apache Maven Checkstyle Plugin 2.11 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Checkstyle Plugin, version 2.11 This plugin integrates checkstyle into the build. http://maven.apache.org/plugins/maven-checkstyle-plugin/ You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-checkstyle-plugin/artifactId version2.11/version /plugin Release Notes - Maven Checkstyle Plugin - Version 2.11 ** Bug * [MCHECKSTYLE-192] - Properties files are only processed in the report, but not in the mojo * [MCHECKSTYLE-193] - Resource files get included regardless of explicit sourceDirectory / includes / excludes configuration * [MCHECKSTYLE-197] - Documentation: Check goal is incorrectly described * [MCHECKSTYLE-202] - The link on Usage page to 'Maven 3.x Compatibility Notes' is not correct ** Improvement * [MCHECKSTYLE-191] - Make name of TreeWalker configurable * [MCHECKSTYLE-199] - Make resource file processing configurable * [MCHECKSTYLE-204] - Errors in the check goal are not very prominent in the Maven output ) Enjoy, -The Apache Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Dependency exclusions being ignored
Jason, I believe that your 2nd pastebin output reflects a bug in the gradle mechanism for determining dependencies. The problem that you have referred to is that you have marked 2 maven plugins to be excluded from the transitive dependencies of abdera-client, because you are seeing the plugins referenced as if they were members of its transitive dependency set. If you look at the gradle tree listing carefully you will see that the gradle has assigned jaxen the version range of jaxen:jaxen:1.1-beta-9 - 1.1.3, and the plugins are listed as dependencies of jaxen. When I forget about gradle and use the maven-dependency-plugin:2.8 and execute mvn dependency:tree with a pom that I simplified to just the issue that you have reported and which you can find below, I don't see the plugins listed as dependencies of jaxen so they do not appear. And I see that the dependency plugin has chosen jaxen 1.1.1 rather than a version range. The pom of jaxen 1.1.1 doesn't list any plugins as its dependents, though I did find at least 1 reference to one of the plugins as a dependency of jaxen's in the pom for 1.1.3. My sense is that you are seeing 1 or more gradle bugs at work here. The pom dependencies look like the following when I trace them: abdera-client has a dependency on abdera-parser abdera-parser has a parent pom abdera in which the dependency-management section chooses jaxen 1.1.1, not a range abdera-parser has a dependency on jaxen which is referenced without a version, so the parent (abdera pom) version of 1.1.1 ought to be in force jaxen 1.1.1 pom has no transitive dependencies on any plugins. It does declare/use plugins within buildplugins but that doesn't count. I did include the the 4 non-plugin dependencies of abdera-client in the exclusions list, and all of them have been excluded. The results of the dependency:tree run appear 1st followed by the pom that I used. Please notice that I commented out the exclusions for the plugins and they are still not being listed. As you can see from the dependency tree's graph below, the gradle report is simply in error. Hope that this helps. C:\java\simple-jpa\jpa-story-parentmvn dependency:tree -f ppom.xml [INFO] Scanning for projects... [INFO] [INFO] [INFO] Building dotcms 2.5.1 [INFO] [INFO] [INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ dotcms --- [INFO] com.dotcms:dotcms:jar:2.5.1 [INFO] \- org.apache.abdera:abdera-client:jar:0.4.0-incubating:compile [INFO]+- org.apache.abdera:abdera-core:jar:0.4.0-incubating:compile [INFO]| +- org.apache.abdera:abdera-i18n:jar:0.4.0-incubating:compile [INFO]| \- commons-codec:commons-codec:jar:1.3:compile [INFO]+- org.apache.abdera:abdera-parser:jar:0.4.0-incubating:compile [INFO]| +- org.codehaus.woodstox:wstx-asl:jar:3.2.1:runtime [INFO]| +- jaxen:jaxen:jar:1.1.1:compile [INFO]| | +- xml-apis:xml-apis:jar:1.3.02:compile [INFO]| | \- xerces:xercesImpl:jar:2.6.2:compile [INFO]| \- commons-logging:commons-logging:jar:1.0.4:compile [INFO]\- commons-httpclient:commons-httpclient:jar:3.1-rc1:compile [INFO] [INFO] BUILD SUCCESS [INFO] [INFO] Total time: 2.119s [INFO] Finished at: Sat Nov 16 12:25:04 EST 2013 [INFO] Final Memory: 10M/121M [INFO] the pom that I used: ?xml version=1.0 encoding=UTF-8? project xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd; xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; modelVersion4.0.0/modelVersion groupIdcom.dotcms/groupId artifactIddotcms/artifactId namedotcms/name version2.5.1/version build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-dependency-plugin/artifactId version2.8/version /plugin /plugins /build dependencies dependency groupIdorg.apache.abdera/groupId artifactIdabdera-client/artifactId version0.4.0-incubating/version exclusions exclusion groupIdorg.apache.geronimo.specs/groupId artifactIdgeronimo-activation_1.0.2_spec/artifactId /exclusion exclusion groupIdorg.apache.geronimo.specs/groupId artifactIdgeronimo-activation_1.1_spec/artifactId /exclusion exclusion groupIdorg.apache.geronimo.specs/groupId artifactIdgeronimo-stax-api_1.0_spec/artifactId /exclusion exclusion groupIdorg.apache.ws.commons.axiom/groupId artifactIdaxiom-impl/artifactId /exclusion !--exclusion--
scm publish instructions
I can't get the github example to work with a multi-module site. I follow the instructions http://maven.apache.org/plugins/maven-scm-publish-plugin/examples/multi-module-configuration.html In spite of the explicit skipDeploy=false in the post-site execution, I still get [INFO] --- maven-site-plugin:3.3:stage-deploy (default-cli) @ bf-sample-lucene-chinese --- [INFO] maven.site.deploy.skip = true: Skipping site deployment Note 'default-cli' and not 'stage-for-scm-publish'. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: scm publish instructions
why site:stage-deploy and not site:stage? I suppose we made a mistake in this doc Regards, Hervé Le samedi 16 novembre 2013 14:51:36 Benson Margulies a écrit : I can't get the github example to work with a multi-module site. I follow the instructions http://maven.apache.org/plugins/maven-scm-publish-plugin/examples/multi-modu le-configuration.html In spite of the explicit skipDeploy=false in the post-site execution, I still get [INFO] --- maven-site-plugin:3.3:stage-deploy (default-cli) @ bf-sample-lucene-chinese --- [INFO] maven.site.deploy.skip = true: Skipping site deployment Note 'default-cli' and not 'stage-for-scm-publish'. - To unsubscribe, e-mail: 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
