[jira] (MCHECKSTYLE-193) Resource files get included regardless of explicit sourceDirectory / includes / excludes configuration
[ https://jira.codehaus.org/browse/MCHECKSTYLE-193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=326870#comment-326870 ] Oleg Kalnichevski commented on MCHECKSTYLE-193: --- [DEBUG] executeCheckstyle start headerLocation : hc-stylecheck/asl2.header [DEBUG] Added 220 source files found in '/home/oleg/src/apache.org/httpcomponents/httpcore/httpcore/src/main/java'. [DEBUG] Added 1 resource files found in '/home/oleg/src/apache.org/httpcomponents/httpcore/httpcore/src/main/resources'. [DEBUG] Added 221 files to process. [DEBUG] The resource 'null' was not found with resourceLoader org.codehaus.plexus.resource.loader.URLResourceLoader. [DEBUG] The resource 'null' was not found with resourceLoader org.codehaus.plexus.resource.loader.JarResourceLoader. [DEBUG] request.getConfigLocation() hc-stylecheck/default.xml [DEBUG] Extension realms for project org.apache.httpcomponents:project:pom:7-SNAPSHOT: (none) [DEBUG] Looking up lifecyle mappings for packaging pom from ClassRealm[plexus.core, parent: null] [DEBUG] Extension realms for project org.apache:apache:pom:13: (none) [DEBUG] Looking up lifecyle mappings for packaging pom from ClassRealm[plexus.core, parent: null] ... [INFO] Starting audit... /home/oleg/src/apache.org/httpcomponents/httpcore/httpcore/src/main/resources/org/apache/http/version.properties:1: Missing a header - not enough lines in file. /home/oleg/src/apache.org/httpcomponents/httpcore/httpcore/src/main/resources/org/apache/http/version.properties:17: Trailing whitespace Resource files get included regardless of explicit sourceDirectory / includes / excludes configuration -- Key: MCHECKSTYLE-193 URL: https://jira.codehaus.org/browse/MCHECKSTYLE-193 Project: Maven 2.x Checkstyle Plugin Issue Type: Bug Affects Versions: 2.10 Reporter: Oleg Kalnichevski Resource files get included into checkstyle audit regardless of explicit sourceDirectory / includes / excludes configuration, which seems wrong to me. I found no way of forcing version 2.10 to revert to the behavior of version 2.9.1 with regards to project resources. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCHECKSTYLE-193) Resource files get included regardless of explicit sourceDirectory / includes / excludes configuration
Oleg Kalnichevski created MCHECKSTYLE-193: - Summary: Resource files get included regardless of explicit sourceDirectory / includes / excludes configuration Key: MCHECKSTYLE-193 URL: https://jira.codehaus.org/browse/MCHECKSTYLE-193 Project: Maven 2.x Checkstyle Plugin Issue Type: Bug Affects Versions: 2.10 Reporter: Oleg Kalnichevski Resource files get included into checkstyle audit regardless of explicit sourceDirectory / includes / excludes configuration, which seems wrong to me. I found no way of forcing version 2.10 to revert to the behavior of version 2.9.1 with regards to project resources. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCHECKSTYLE-194) Stylecheck audit invoked on intermedaite files generated by Clover2 plugin
[ https://jira.codehaus.org/browse/MCHECKSTYLE-194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=326882#comment-326882 ] Oleg Kalnichevski commented on MCHECKSTYLE-194: --- [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ httpcore --- [INFO] Deleting /home/oleg/src/apache.org/httpcomponents/httpcore/httpcore/target [INFO] [INFO] --- maven-clover2-plugin:3.1.10.1:setup (default-cli) @ httpcore --- [INFO] Clover Version 3.1.10, built on January 08 2013 (build-885) [INFO] Loaded from: /home/oleg/.m2/repository/com/cenqua/clover/clover/3.1.10/clover-3.1.10.jar [INFO] Clover: Open Source License registered to Apache. [INFO] Creating new database at '/home/oleg/src/apache.org/httpcomponents/httpcore/httpcore/target/clover/clover.db'. [INFO] Processing files at 1.6 source level. [INFO] Clover all over. Instrumented 220 files (15 packages). [INFO] Elapsed time = 1.585 secs. (138.801 files/sec, 18,435.961 srclines/sec) [INFO] Clover Version 3.1.10, built on January 08 2013 (build-885) [INFO] Loaded from: /home/oleg/.m2/repository/com/cenqua/clover/clover/3.1.10/clover-3.1.10.jar [INFO] Clover: Open Source License registered to Apache. [INFO] Updating existing database at '/home/oleg/src/apache.org/httpcomponents/httpcore/httpcore/target/clover/clover.db'. [INFO] Processing files at 1.6 source level. [INFO] Clover all over. Instrumented 88 files (15 packages). [INFO] 633 test methods detected. [INFO] Elapsed time = 0.76 secs. (115.789 files/sec, 22,477.633 srclines/sec) [INFO] [INFO] --- maven-checkstyle-plugin:2.9.1:checkstyle (validate) @ httpcore --- [INFO] Starting audit... /home/oleg/src/apache.org/httpcomponents/httpcore/httpcore/target/clover/src-instrumented/org/apache/http/ProtocolException.java:1: Line does not match expected header line of '/*'. /home/oleg/src/apache.org/httpcomponents/httpcore/httpcore/target/clover/src-instrumented/org/apache/http/concurrent/Cancellable.java:1: Line does not match expected header line of '/*'. Stylecheck audit invoked on intermedaite files generated by Clover2 plugin -- Key: MCHECKSTYLE-194 URL: https://jira.codehaus.org/browse/MCHECKSTYLE-194 Project: Maven 2.x Checkstyle Plugin Issue Type: Bug Affects Versions: 2.10 Reporter: Oleg Kalnichevski This issue may not necessarily be a problem with Maven Stylecheck plugin but I just unable to pinpoint the exact culprit here and the Stylecheck appears to be trying to audit intermediate files generated by Clover2 report. I am really unsure how to approach this problem. Please let me know if you need more info -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCHECKSTYLE-194) Stylecheck audit invoked on intermedaite files generated by Clover2 plugin
Oleg Kalnichevski created MCHECKSTYLE-194: - Summary: Stylecheck audit invoked on intermedaite files generated by Clover2 plugin Key: MCHECKSTYLE-194 URL: https://jira.codehaus.org/browse/MCHECKSTYLE-194 Project: Maven 2.x Checkstyle Plugin Issue Type: Bug Affects Versions: 2.10 Reporter: Oleg Kalnichevski This issue may not necessarily be a problem with Maven Stylecheck plugin but I just unable to pinpoint the exact culprit here and the Stylecheck appears to be trying to audit intermediate files generated by Clover2 report. I am really unsure how to approach this problem. Please let me know if you need more info -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5485) ClassRealmAdapter.getParent() handles null parents incorrectly
Stefan Fromm created MNG-5485: - Summary: ClassRealmAdapter.getParent() handles null parents incorrectly Key: MNG-5485 URL: https://jira.codehaus.org/browse/MNG-5485 Project: Maven 2 3 Issue Type: Bug Affects Versions: 3.0.5 Environment: Java 1.6.0_30, Windows XP Professional 2002 SP3 Reporter: Stefan Fromm Here is the code from plexus classworlds 2.4.x. {noformat} public ClassRealm getParent() { return ClassRealmAdapter.getInstance( realm.getParentRealm() ); } public ClassRealm getParentRealm() { return ClassRealmAdapter.getInstance( realm.getParentRealm() ); } public static ClassRealmAdapter getInstance( org.codehaus.plexus.classworlds.realm.ClassRealm newRealm ) { ClassRealmAdapter adapter = new ClassRealmAdapter( newRealm ); return adapter; } {noformat} If the parent of the backend realm is {{null}}, then there is returned a new {{ClassRealmAdapter}} instead of {{null}}. Calling methods on the returned {{ClassRealmAdapter}} produces NPEs. I think, that {{getParent()}} and {{getParentRealm()}} could be patched like this: {noformat} public ClassRealm getParentRealm() { return realm.getParentRealm() != null ? ClassRealmAdapter.getInstance( realm.getParentRealm()) : null; } public ClassRealm getParent() { return getParentRealm(); } {noformat} Or should {{null}} be handled in {{ClassRealmAdapter.getInstance()}}? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (WAGON-381) Both Maven 2 and 3 fail to retrieve a dependency that is larger than Integer.MAX_VALUE
[ https://jira.codehaus.org/browse/WAGON-381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=326915#comment-326915 ] Olivier Lamy commented on WAGON-381: still weird for me. I added a unit test https://git-wip-us.apache.org/repos/asf?p=maven-wagon.git;a=commit;h=05098b3f0f0378a7272f0d9491ef356889bfc67f And those huge files (with Content-Length or Chunked) are correctly downloaded. Both Maven 2 and 3 fail to retrieve a dependency that is larger than Integer.MAX_VALUE Key: WAGON-381 URL: https://jira.codehaus.org/browse/WAGON-381 Project: Maven Wagon Issue Type: Bug Components: wagon-http Affects Versions: 2.2 Reporter: Evgeny Goldin Assignee: Olivier Lamy Fix For: 2.5 Attachments: 1.png, 2.png We have a *{{*.tar}}* file stored in corporate Maven repository, its size is *{{2.5Gb}}*. Trying to bring it with Maven (both 2 and 3) causes file of *{{2147483647}}* size to be downloaded to local maven repo, which is exactly 2sup31/sup-1. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MPOM-44) Compiler version settings cannot be overridden by defining maven.compiler.source/target
Sebb created MPOM-44: Summary: Compiler version settings cannot be overridden by defining maven.compiler.source/target Key: MPOM-44 URL: https://issues.apache.org/jira/browse/MPOM-44 Project: Maven POMs Issue Type: Bug Components: maven-plugins Affects Versions: ASF-13 Reporter: Sebb The compiler plugin by default picks up the source and target from the properties maven.compiler.source and maven.compiler.target. Unfortunately, the Apache POM uses the following fixed values to specify the version: {code} build pluginManagement plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId version2.5.1/version configuration source1.4/source target1.4/target /configuration {code} This means that child poms which use the properties expecting them to be honoured have to override the configuration as follows: {code} plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId configuration source${maven.compile.source}/source target${maven.compile.target}/target /configuration /plugin {code} This is unnecessary and wrong. For compatibility, the Apache Pom does need to still specify the default source/target as 1.4 (the plugin default is 1.5), but it should do so by using the standard properties which can then be overridden. In fact, if the properties are defined, the compiler plugin config could be dropped, as it is the default behaviour. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MPOM-44) Compiler version settings cannot be overridden by defining maven.compiler.source/target
[ https://issues.apache.org/jira/browse/MPOM-44?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated MPOM-44: - Attachment: MPOM-44.patch Compiler version settings cannot be overridden by defining maven.compiler.source/target --- Key: MPOM-44 URL: https://issues.apache.org/jira/browse/MPOM-44 Project: Maven POMs Issue Type: Bug Components: maven-plugins Affects Versions: ASF-13 Reporter: Sebb Attachments: MPOM-44.patch The compiler plugin by default picks up the source and target from the properties maven.compiler.source and maven.compiler.target. Unfortunately, the Apache POM uses the following fixed values to specify the version: {code} build pluginManagement plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId version2.5.1/version configuration source1.4/source target1.4/target /configuration {code} This means that child poms which use the properties expecting them to be honoured have to override the configuration as follows: {code} plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId configuration source${maven.compile.source}/source target${maven.compile.target}/target /configuration /plugin {code} This is unnecessary and wrong. For compatibility, the Apache Pom does need to still specify the default source/target as 1.4 (the plugin default is 1.5), but it should do so by using the standard properties which can then be overridden. In fact, if the properties are defined, the compiler plugin config could be dropped, as it is the default behaviour. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-431) Configuration of policy for calculating next (release) version
[ https://jira.codehaus.org/browse/MRELEASE-431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated MRELEASE-431: - Attachment: 0001-MRELEASE-431-Configuration-of-policy-for-calculating.patch Configuration of policy for calculating next (release) version -- Key: MRELEASE-431 URL: https://jira.codehaus.org/browse/MRELEASE-431 Project: Maven 2.x Release Plugin Issue Type: New Feature Components: prepare Affects Versions: 2.0-beta-8 Reporter: Carsten Ziegeler Attachments: 0001-MRELEASE-431-Configuration-of-policy-for-calculating.patch Currently, when preparing the release, the version to release is always the next version which usually is the current version without the snapshot extension. There are quiet a lot projects (Apache Felix, Sling and others) following an even release numbering policy. So while the current development version is odd (like 1.2.3-SNAPSHOT), the next released version will be 1.2.4. It would be nice if this could be made configuration through some configuration property like versionPolicynext-even/versionPolicy (with possible values being: next (default, as-is), next-even, next-odd I briefly scanned through the code and it seems that adding support for this requires changes in both, the release-manager and the release-plugin. If this feature gets accepted and if someone could give me some minor hints how/where to add this I could come up with a patch. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-431) Configuration of policy for calculating next (release) version
[ https://jira.codehaus.org/browse/MRELEASE-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=326938#comment-326938 ] Robert Munteanu commented on MRELEASE-431: -- I've attached a patch which adds a 'versionPolicy' property to the plugin. Possible values are 'default' - which is what the plugin does today - and 'odd-even', which ensures that snapshot dependencies are always odd and release versions are always even. You can also review the [commit on github|https://github.com/rombert/release/commit/35e42901868d5c18289e6687bbecdd78cddbf03e] as well. I tried to keep changes minimal and self-contained and also added tests as well as I could. I'm open to iterating on this so please let me know what you think. Thanks! Robert Configuration of policy for calculating next (release) version -- Key: MRELEASE-431 URL: https://jira.codehaus.org/browse/MRELEASE-431 Project: Maven 2.x Release Plugin Issue Type: New Feature Components: prepare Affects Versions: 2.0-beta-8 Reporter: Carsten Ziegeler Attachments: 0001-MRELEASE-431-Configuration-of-policy-for-calculating.patch Currently, when preparing the release, the version to release is always the next version which usually is the current version without the snapshot extension. There are quiet a lot projects (Apache Felix, Sling and others) following an even release numbering policy. So while the current development version is odd (like 1.2.3-SNAPSHOT), the next released version will be 1.2.4. It would be nice if this could be made configuration through some configuration property like versionPolicynext-even/versionPolicy (with possible values being: next (default, as-is), next-even, next-odd I briefly scanned through the code and it seems that adding support for this requires changes in both, the release-manager and the release-plugin. If this feature gets accepted and if someone could give me some minor hints how/where to add this I could come up with a patch. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-431) Configuration of policy for calculating next (release) version
[ https://jira.codehaus.org/browse/MRELEASE-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=326943#comment-326943 ] Robert Scholte commented on MRELEASE-431: - There are a lot of issues related to version policies. I could try to collect all wishes, but I'm afraid that I'll forget a few and that in the near future developers invent more exotic ways of version policies. To prevent this, we should define a {{VersionPolicyManager}} interface (probably in the separated {{api}}-project), so everyone can code his own version. It'll be just a matter of injecting your preferred implementation. I'm not sure if I should introduce a {{release-api}} project for this or start a new shared component. With the latter we could also reuse it for the versions-maven-plugin. Configuration of policy for calculating next (release) version -- Key: MRELEASE-431 URL: https://jira.codehaus.org/browse/MRELEASE-431 Project: Maven 2.x Release Plugin Issue Type: New Feature Components: prepare Affects Versions: 2.0-beta-8 Reporter: Carsten Ziegeler Attachments: 0001-MRELEASE-431-Configuration-of-policy-for-calculating.patch Currently, when preparing the release, the version to release is always the next version which usually is the current version without the snapshot extension. There are quiet a lot projects (Apache Felix, Sling and others) following an even release numbering policy. So while the current development version is odd (like 1.2.3-SNAPSHOT), the next released version will be 1.2.4. It would be nice if this could be made configuration through some configuration property like versionPolicynext-even/versionPolicy (with possible values being: next (default, as-is), next-even, next-odd I briefly scanned through the code and it seems that adding support for this requires changes in both, the release-manager and the release-plugin. If this feature gets accepted and if someone could give me some minor hints how/where to add this I could come up with a patch. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MDEP-406) skip is ignored
[ https://jira.codehaus.org/browse/MDEP-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=326954#comment-326954 ] Peter Kahn commented on MDEP-406: - I think it is this as I too have this problem. The skip setting in the configuration for at least the copy-dependencies mojo doesn't appear to work properly. I would expect the skip xml below to skip the execution, but it does not. h2. Goal Conditionally execute copy-dependencies for specific modules in my project. h2. Approach * Top level pom defines copy-dependency execution using property *skipIncludeCompileDeps* to control execution * Top level pom sets *skipIncludeCompileDeps* to true * Child poms will automatically skip execution unless they override property definition h2. Root Pom {code} properties skipIncludeCompileDepstrue/skipIncludeCompileDeps /properties build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-dependency-plugin/artifactId executions execution idROOT POM: Gather Compile Dependencies For Scan/id phasevalidate/phase goals goalcopy-dependencies/goal /goals configuration skiptrue/skip includeScopecompile/includeScope outputDirectory${project.build.directory}/compileScopeDependencies/outputDirectory /configuration /execution /executions /plugin /plugins /build {code} h2. Module Using common execution to gather deps {code} ... properties skipIncludeCompileDepsfalse/skipIncludeCompileDeps /properties{code} skip is ignored --- Key: MDEP-406 URL: https://jira.codehaus.org/browse/MDEP-406 Project: Maven 2.x Dependency Plugin Issue Type: Bug Affects Versions: 2.7 Environment: Maven 3.0.4, Dependency Plugin 2.7 Reporter: H.-C. Gürsoy I've a build there I've to skip dependency resolution. According to the 2.7 documentation, using the skip parameter should prevent from running the whole plugin execution. Call mvn with -Dmdep.skip=true or setting skip to true in the plugin configuration with {code} plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-dependency-plugin/artifactId version2.7/version configuration skiptrue/skip /configuration /plugin {code} is allways ignored. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MDEP-406) skip is ignored
[ https://jira.codehaus.org/browse/MDEP-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=326955#comment-326955 ] Peter Kahn commented on MDEP-406: - Actually, this works for me. I checked my effective pom and found I used version 2.4 which didn't yet support the feature. Thanks and apologies for the churn skip is ignored --- Key: MDEP-406 URL: https://jira.codehaus.org/browse/MDEP-406 Project: Maven 2.x Dependency Plugin Issue Type: Bug Affects Versions: 2.7 Environment: Maven 3.0.4, Dependency Plugin 2.7 Reporter: H.-C. Gürsoy I've a build there I've to skip dependency resolution. According to the 2.7 documentation, using the skip parameter should prevent from running the whole plugin execution. Call mvn with -Dmdep.skip=true or setting skip to true in the plugin configuration with {code} plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-dependency-plugin/artifactId version2.7/version configuration skiptrue/skip /configuration /plugin {code} is allways ignored. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-431) Configuration of policy for calculating next (release) version
[ https://jira.codehaus.org/browse/MRELEASE-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=326956#comment-326956 ] Robert Munteanu commented on MRELEASE-431: -- Right, so I'll create a VersionPolicyManager interface, and I can look it up based on the configured versionPolicy parameter. What I'm not sure is how to actually provide and look up implementations for this interface, since I'm not familiar with Maven component wiring. Where can I find the docs or a working example? And for now I can add a release-api project to the release reactor, and you can decide whether to move it to a shared component later, since it would be more difficult for me, not being a Maven committer. WDYT? Configuration of policy for calculating next (release) version -- Key: MRELEASE-431 URL: https://jira.codehaus.org/browse/MRELEASE-431 Project: Maven 2.x Release Plugin Issue Type: New Feature Components: prepare Affects Versions: 2.0-beta-8 Reporter: Carsten Ziegeler Attachments: 0001-MRELEASE-431-Configuration-of-policy-for-calculating.patch Currently, when preparing the release, the version to release is always the next version which usually is the current version without the snapshot extension. There are quiet a lot projects (Apache Felix, Sling and others) following an even release numbering policy. So while the current development version is odd (like 1.2.3-SNAPSHOT), the next released version will be 1.2.4. It would be nice if this could be made configuration through some configuration property like versionPolicynext-even/versionPolicy (with possible values being: next (default, as-is), next-even, next-odd I briefly scanned through the code and it seems that adding support for this requires changes in both, the release-manager and the release-plugin. If this feature gets accepted and if someone could give me some minor hints how/where to add this I could come up with a patch. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-431) Configuration of policy for calculating next (release) version
[ https://jira.codehaus.org/browse/MRELEASE-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=326957#comment-326957 ] Robert Scholte commented on MRELEASE-431: - There are at least two options: - through Plexus Components ( example is [Maven Compiler Plugin|http://maven.apache.org/plugins/maven-compiler-plugin/xref/org/apache/maven/plugin/compiler/AbstractCompilerMojo.html#420] where you can choose a compiler by its id. Implementations are marked as a Component and can be chosen by the hint. - through Plexus Configuration. I couldn't find a good example, but it should be something like this: {code:xml} configuration versionPolicyManager implementation=com.acme.custom.MyVersionPolicyManager /versionPolicyManager /configuration {code} The advantage of the latter is that it is very straightforward if you want to use additional fields/setters on your VersionPolicyManager. For that reason this would be my choice right now. Configuration of policy for calculating next (release) version -- Key: MRELEASE-431 URL: https://jira.codehaus.org/browse/MRELEASE-431 Project: Maven 2.x Release Plugin Issue Type: New Feature Components: prepare Affects Versions: 2.0-beta-8 Reporter: Carsten Ziegeler Attachments: 0001-MRELEASE-431-Configuration-of-policy-for-calculating.patch Currently, when preparing the release, the version to release is always the next version which usually is the current version without the snapshot extension. There are quiet a lot projects (Apache Felix, Sling and others) following an even release numbering policy. So while the current development version is odd (like 1.2.3-SNAPSHOT), the next released version will be 1.2.4. It would be nice if this could be made configuration through some configuration property like versionPolicynext-even/versionPolicy (with possible values being: next (default, as-is), next-even, next-odd I briefly scanned through the code and it seems that adding support for this requires changes in both, the release-manager and the release-plugin. If this feature gets accepted and if someone could give me some minor hints how/where to add this I could come up with a patch. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPLUGIN-237) JavaDoc WARNING on generated HelpMojo class.
[ https://jira.codehaus.org/browse/MPLUGIN-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=326959#comment-326959 ] SebbASF commented on MPLUGIN-237: - Agreed; the @author and @version fields could be dropped. Alternatively, they could be used to document the name and version of the plugin that creates the file ... JavaDoc WARNING on generated HelpMojo class. Key: MPLUGIN-237 URL: https://jira.codehaus.org/browse/MPLUGIN-237 Project: Maven 2.x Plugin Tools Issue Type: Improvement Components: Plugin Plugin Affects Versions: 3.2 Reporter: Karl Heinz Marbaise Priority: Minor During the site generation of a maven-plugin i got the following warning in the builds: {code} 2 warnings [WARNING] Javadoc Warnings [WARNING] /opt/.../plugin/.../HelpMojo.java:30: warning - @author tag has no arguments. [WARNING] /opt/.../plugin/.../HelpMojo.java:30: warning - @version tag has no arguments. [INFO] Generating Test JavaDocs report--- maven-javadoc-plugin:2.9 {code} The question is: Can this be automatically be generated by the maven-plugin-plugin from the original Mojo Class to avoid this WARNING? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPLUGIN-245) @Parameter property names are not written to the plugin-help.xml file
SebbASF created MPLUGIN-245: --- Summary: @Parameter property names are not written to the plugin-help.xml file Key: MPLUGIN-245 URL: https://jira.codehaus.org/browse/MPLUGIN-245 Project: Maven 2.x Plugin Tools Issue Type: Bug Reporter: SebbASF The generated HelpMojo fails to show user parameter names if the Mojo is generated from Java 5 annotations. This appears to be because the plugin-help.xml file does not include the information. HelpMojo.java is expecting to find an expression tag. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira