[jira] (MNG-5430) use wagon 2.4
[ https://jira.codehaus.org/browse/MNG-5430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated MNG-5430: -- Fix Version/s: 3.0.5 Assignee: Olivier Lamy use wagon 2.4 - Key: MNG-5430 URL: https://jira.codehaus.org/browse/MNG-5430 Project: Maven 2 3 Issue Type: Bug Components: Dependencies Affects Versions: 3.0.4 Reporter: Olivier Lamy Assignee: Olivier Lamy Fix For: 3.0.5 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5430) use wagon 2.4
Olivier Lamy created MNG-5430: - Summary: use wagon 2.4 Key: MNG-5430 URL: https://jira.codehaus.org/browse/MNG-5430 Project: Maven 2 3 Issue Type: Bug Components: Dependencies Affects Versions: 3.0.4 Reporter: Olivier Lamy -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5430) use wagon 2.4
[ https://jira.codehaus.org/browse/MNG-5430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated MNG-5430: -- Priority: Blocker (was: Major) use wagon 2.4 - Key: MNG-5430 URL: https://jira.codehaus.org/browse/MNG-5430 Project: Maven 2 3 Issue Type: Bug Components: Dependencies Affects Versions: 3.0.4 Reporter: Olivier Lamy Assignee: Olivier Lamy Priority: Blocker Fix For: 3.0.5 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-952) Incompatibility with future release 4.12 of junit (Categories)
[ https://jira.codehaus.org/browse/SUREFIRE-952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Gross closed SUREFIRE-952. -- Resolution: Not A Bug Incompatibility with future release 4.12 of junit (Categories) -- Key: SUREFIRE-952 URL: https://jira.codehaus.org/browse/SUREFIRE-952 Project: Maven Surefire Issue Type: Bug Components: Junit 4.x support Affects Versions: 2.12.2, 2.12.4 Reporter: Henning Gross Priority: Blocker Attachments: surefire-952.zip Junit is introducing some interesting new features on Categories in 4.12. @Category will become @Inherited and @ExcludeCategory/@IncludeCategory will accept a class-array instead of just a single class. As we need these urgently we are currently testing with the current snapshot of junit (https://oss.sonatype.org/content/repositories/snapshots/junit/junit/4.12-SNAPSHOT/). Unfortuneately the version seems to be incompatible. All tests are executed always. Regardless of the settings in groups or excludedgroups. Using 4.11 works fine. I do not know why this happens and therefore cannot provide a patch but I would love to see it fixed. If someone points me at the cause I will happily find a solution. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (ARCHETYPE-428) Improve Generate project in batch mode doc page
[ https://jira.codehaus.org/browse/ARCHETYPE-428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anders Hammar reassigned ARCHETYPE-428: --- Assignee: Anders Hammar Improve Generate project in batch mode doc page --- Key: ARCHETYPE-428 URL: https://jira.codehaus.org/browse/ARCHETYPE-428 Project: Maven Archetype Issue Type: Improvement Components: Documentation Affects Versions: 2.2 Environment: n/a Reporter: Anders Hammar Assignee: Anders Hammar Priority: Minor The Generate project in batch mode doc page could be improved: * Update according to output from latest plugin version * Change 1.5 package name to something better * Version of created project should be 1.0-SNAPSHOT to conform to Maven best practices -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (ARCHETYPE-428) Improve Generate project in batch mode doc page
Anders Hammar created ARCHETYPE-428: --- Summary: Improve Generate project in batch mode doc page Key: ARCHETYPE-428 URL: https://jira.codehaus.org/browse/ARCHETYPE-428 Project: Maven Archetype Issue Type: Improvement Components: Documentation Affects Versions: 2.2 Environment: n/a Reporter: Anders Hammar Priority: Minor The Generate project in batch mode doc page could be improved: * Update according to output from latest plugin version * Change 1.5 package name to something better * Version of created project should be 1.0-SNAPSHOT to conform to Maven best practices -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (ARCHETYPE-428) Improve Generate project in batch mode doc page
[ https://jira.codehaus.org/browse/ARCHETYPE-428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anders Hammar closed ARCHETYPE-428. --- Resolution: Fixed Fix Version/s: 2.3 Fixed in [r1442075|http://svn.apache.org/r1442075] with output from plugin v2.2. Improve Generate project in batch mode doc page --- Key: ARCHETYPE-428 URL: https://jira.codehaus.org/browse/ARCHETYPE-428 Project: Maven Archetype Issue Type: Improvement Components: Documentation Affects Versions: 2.2 Environment: n/a Reporter: Anders Hammar Assignee: Anders Hammar Priority: Minor Fix For: 2.3 The Generate project in batch mode doc page could be improved: * Update according to output from latest plugin version * Change 1.5 package name to something better * Version of created project should be 1.0-SNAPSHOT to conform to Maven best practices -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (ARCHETYPE-429) JIRA report in site only shows fixes up to v2.1 of plugin
Anders Hammar created ARCHETYPE-429: --- Summary: JIRA report in site only shows fixes up to v2.1 of plugin Key: ARCHETYPE-429 URL: https://jira.codehaus.org/browse/ARCHETYPE-429 Project: Maven Archetype Issue Type: Bug Components: Documentation Affects Versions: 2.2 Environment: n/a Reporter: Anders Hammar Priority: Minor The plugin's site has a JIRA report than only shows versions 2.1, 2.0, 2.0-alpha-5. This should be updated according to Apache Maven project plugin standards. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (ARCHETYPE-429) JIRA report in site only shows fixes up to v2.1 of plugin
[ https://jira.codehaus.org/browse/ARCHETYPE-429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anders Hammar reassigned ARCHETYPE-429: --- Assignee: Anders Hammar JIRA report in site only shows fixes up to v2.1 of plugin - Key: ARCHETYPE-429 URL: https://jira.codehaus.org/browse/ARCHETYPE-429 Project: Maven Archetype Issue Type: Bug Components: Documentation Affects Versions: 2.2 Environment: n/a Reporter: Anders Hammar Assignee: Anders Hammar Priority: Minor The plugin's site has a JIRA report than only shows versions 2.1, 2.0, 2.0-alpha-5. This should be updated according to Apache Maven project plugin standards. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (ARCHETYPE-429) JIRA report in site only shows fixes up to v2.1 of plugin
[ https://jira.codehaus.org/browse/ARCHETYPE-429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=318646#comment-318646 ] Anders Hammar commented on ARCHETYPE-429: - Checking several of the core plugins, I only found the JIRA report in the m-plugin-p's site. I think we should remove this report as it doesn't add much information. If someone is interested in what has been fixed that info can be accessed directly from JIRA instead. JIRA report in site only shows fixes up to v2.1 of plugin - Key: ARCHETYPE-429 URL: https://jira.codehaus.org/browse/ARCHETYPE-429 Project: Maven Archetype Issue Type: Bug Components: Documentation Affects Versions: 2.2 Environment: n/a Reporter: Anders Hammar Assignee: Anders Hammar Priority: Minor The plugin's site has a JIRA report than only shows versions 2.1, 2.0, 2.0-alpha-5. This should be updated according to Apache Maven project plugin standards. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSITE-682) Apostrophe's in Markdown are removed resulting in HTML full of spelling error
[ https://jira.codehaus.org/browse/MSITE-682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=318647#comment-318647 ] Alex Collins commented on MSITE-682: Naturally I mean spelling errors not spelling error. Which is a grammatical error. Apostrophe's in Markdown are removed resulting in HTML full of spelling error - Key: MSITE-682 URL: https://jira.codehaus.org/browse/MSITE-682 Project: Maven 2.x and 3.x Site Plugin Issue Type: Bug Affects Versions: 3.1 Reporter: Alex Collins Repro: 1. Create Maven 3 project. 2. Add site 3.1 to plugins, add doxia-markdown-module:1.3 to plugin deps. 3. Create src/site/markdown/test.md containing a sentence with an apostrophe. 4. mvn site 5. Examine target/site/test.md. Expected: sentence would be reproduced with apos. Actual: sentence is missing apos. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSITE-682) Apostrophe's in Markdown are removed resulting in HTML full of spelling error
Alex Collins created MSITE-682: -- Summary: Apostrophe's in Markdown are removed resulting in HTML full of spelling error Key: MSITE-682 URL: https://jira.codehaus.org/browse/MSITE-682 Project: Maven 2.x and 3.x Site Plugin Issue Type: Bug Affects Versions: 3.1 Reporter: Alex Collins Repro: 1. Create Maven 3 project. 2. Add site 3.1 to plugins, add doxia-markdown-module:1.3 to plugin deps. 3. Create src/site/markdown/test.md containing a sentence with an apostrophe. 4. mvn site 5. Examine target/site/test.md. Expected: sentence would be reproduced with apos. Actual: sentence is missing apos. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (ARCHETYPE-429) JIRA report in site only shows fixes up to v2.1 of plugin
[ https://jira.codehaus.org/browse/ARCHETYPE-429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anders Hammar closed ARCHETYPE-429. --- Resolution: Fixed Fix Version/s: 2.3 JIRA report removed in [r1442099|http://svn.apache.org/r1442099] JIRA report in site only shows fixes up to v2.1 of plugin - Key: ARCHETYPE-429 URL: https://jira.codehaus.org/browse/ARCHETYPE-429 Project: Maven Archetype Issue Type: Bug Components: Documentation Affects Versions: 2.2 Environment: n/a Reporter: Anders Hammar Assignee: Anders Hammar Priority: Minor Fix For: 2.3 The plugin's site has a JIRA report than only shows versions 2.1, 2.0, 2.0-alpha-5. This should be updated according to Apache Maven project plugin standards. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MDEP-301) Allow build-classpath to output to property
[ https://jira.codehaus.org/browse/MDEP-301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MDEP-301. - Resolution: Fixed Fix Version/s: 2.7 Assignee: Olivier Lamy applied http://svn.apache.org/r1442131 Thanks for the patch ! Allow build-classpath to output to property --- Key: MDEP-301 URL: https://jira.codehaus.org/browse/MDEP-301 Project: Maven 2.x Dependency Plugin Issue Type: Improvement Components: build-classpath Affects Versions: 2.1 Reporter: Bjorn Beskow Assignee: Olivier Lamy Fix For: 2.7 Attachments: build-path-to-property.patch, mdep-301.diff, mdep-301.diff I frequently have the need to set the bootClasspath for the compiler plugin, and would like to do it from project dependencies. Hence I would like to be able to get the output of build-classpath to a property instead of a file. Attached is a patch which adds an outputProperty property, and assigns the classpath value to it if specified. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MJARSIGNER-24) Use Password Encryption in pom.xml
[ https://jira.codehaus.org/browse/MJARSIGNER-24?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=318657#comment-318657 ] Olivier Lamy commented on MJARSIGNER-24: @Jerome feel free to provide patches for all bugs !! I'm pretty sure you will find some to work one ;-) Use Password Encryption in pom.xml -- Key: MJARSIGNER-24 URL: https://jira.codehaus.org/browse/MJARSIGNER-24 Project: Maven 2.x Jar Signer Plugin Issue Type: New Feature Reporter: Zang MingJie Attachments: jarsigner.patch, patch, securejarsigner.patch See http://maven.apache.org/guides/mini/guide-encryption.html Here is a patch for it -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPMD-161) PMD/CPD violation exclusions by class/issue
[ https://jira.codehaus.org/browse/MPMD-161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=318660#comment-318660 ] Olivier Lamy commented on MPMD-161: --- not really :-) We now use mojo annotations. Furthermore a unit or it test will be welcome for such new feature. Thanks ! PMD/CPD violation exclusions by class/issue --- Key: MPMD-161 URL: https://jira.codehaus.org/browse/MPMD-161 Project: Maven 2.x PMD Plugin Issue Type: New Feature Components: CPD, PMD Reporter: Andrey Utis Assignee: Olivier Lamy Fix For: 3.0 Attachments: pmd2.7.1_exclusions2.patch, pmd_exclude_trunk.patch I work on a system that has a lot of legacy code with a lot of PMD/CPD violations. Introducing PMD to the build is not an easy option, since the build would always fail. So the next best thing is to exclude any existing violations and only fail if a new violation is introduced. Unfortunately, if I have thousands of violations, PMD doesn't provide a good way to do this. I'd have to add comments or annotations to all these places to ignore the violation. We came up with an alternative solution to this. We modified the PMD plugin to read a properties file that contains a mapping of class name to a list of excluded violations. If a particular violation is in this file, it does not cause the build to fail. Similar idea for CPD. An svn patch is attached (apply to 2.7.1) (Disclaimer: this is probably not the most elegant piece of code but it works and it was quick. Feel free to re-factor and make it more in line with the rest of the plugin code) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCOMPILER-132) Provide general maven.compiler.main.skip attribute
[ https://jira.codehaus.org/browse/MCOMPILER-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=318662#comment-318662 ] Matthew Adams commented on MCOMPILER-132: - @Olivier, I suppose I agree with you about #3. Better to be explicit there. Provide general maven.compiler.main.skip attribute Key: MCOMPILER-132 URL: https://jira.codehaus.org/browse/MCOMPILER-132 Project: Maven 2.x Compiler Plugin Issue Type: New Feature Reporter: Dieter König Assignee: Olivier Lamy Priority: Minor Fix For: 3.1 Please provide general maven.compiler.main.skip attribute which will allow to skip all executions of compiler plugin. Desired usecase: Execution of profile's where compilation of sources is not needed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5181) New resolution from local repository is very confusing
[ https://jira.codehaus.org/browse/MNG-5181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=318665#comment-318665 ] Brian Fox commented on MNG-5181: i'm on the fence about if this is good or not, but I think the option if provided should be simple-local-repository without the manager part. People already get confused about what's a local repo vs what's a repository manager and the mixing of these concepts here will make that worse. New resolution from local repository is very confusing -- Key: MNG-5181 URL: https://jira.codehaus.org/browse/MNG-5181 Project: Maven 2 3 Issue Type: Improvement Components: Dependencies Affects Versions: 3.0, 3.0.1, 3.0.2, 3.0.3 Reporter: Arnaud Heritier Assignee: Olivier Lamy Fix For: 3.1.0 I just discover the change introduced in Maven 3.x to try to improve the resolution mechanism and to avoid to use a local artifact which may not be available in its remote repository : https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-ResolutionfromLocalRepository Even if the feature is interesting it has several problems : # When an artifact isn't accessible from its remote repository it isn't used by maven which replies a classical dependency not found error. It is really annoying for a user with some Maven 2 skills which will have a look at his local repo, will find the artifact and won't understand why Maven doesn't use it. At least the error reported by Maven should be clear that even if the dependency is available locally, it isn't used because it's remote repository isn't available. # This behavior cannot be configured to be only a warning for example. It is really annoying because it doesn't take care of some context and constraints we may have in a development team. Let's imagine that the remote artifact is really removed. Cool Maven broke the build to warn us. But it brakes the build of all the team whereas perhaps only one of them may try to solve the issue (and it can be a long resolution). Thus having the ability to configure if this control is blocker or warning may allow the team to configure it as blocker on the CI server and as warning on the development environment. # This behavior may introduce some bad practices for example when we are using a staging feature on a repository manager. In our case my teams have a dedicated profile to activate a staging repository when we are validating a release. I recommend to not have this profile always activated but to do it only on-demand to avoid them to DL staging stuffs they don't need. With this new feature they need for all builds they run to activate this staging profile while binaries are stored in it. When you have to do it 20 times per day minimum let's imagine what the developer does : It adds it as an alwaysActive profile and then forget to remove it when the release is ended. For all these reason I would like we improve this feature to make it more usable and before all bet understandable for ours users. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPMD-161) PMD/CPD violation exclusions by class/issue
[ https://jira.codehaus.org/browse/MPMD-161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Utis updated MPMD-161: - Attachment: pmd_exclude_trunk_v2.patch I added annotations for the parameters passed from the pom. Is that what you meant? I also added unit tests in a similar style to what was already there. Let me know if this is what you need. Thanks. PMD/CPD violation exclusions by class/issue --- Key: MPMD-161 URL: https://jira.codehaus.org/browse/MPMD-161 Project: Maven 2.x PMD Plugin Issue Type: New Feature Components: CPD, PMD Reporter: Andrey Utis Assignee: Olivier Lamy Fix For: 3.0 Attachments: pmd2.7.1_exclusions2.patch, pmd_exclude_trunk.patch, pmd_exclude_trunk_v2.patch I work on a system that has a lot of legacy code with a lot of PMD/CPD violations. Introducing PMD to the build is not an easy option, since the build would always fail. So the next best thing is to exclude any existing violations and only fail if a new violation is introduced. Unfortunately, if I have thousands of violations, PMD doesn't provide a good way to do this. I'd have to add comments or annotations to all these places to ignore the violation. We came up with an alternative solution to this. We modified the PMD plugin to read a properties file that contains a mapping of class name to a list of excluded violations. If a particular violation is in this file, it does not cause the build to fail. Similar idea for CPD. An svn patch is attached (apply to 2.7.1) (Disclaimer: this is probably not the most elegant piece of code but it works and it was quick. Feel free to re-factor and make it more in line with the rest of the plugin code) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPMD-161) PMD/CPD violation exclusions by class/issue
[ https://jira.codehaus.org/browse/MPMD-161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=318676#comment-318676 ] Olivier Lamy edited comment on MPMD-161 at 2/4/13 2:53 PM: --- fixed http://svn.apache.org/r1442345 Thanks ! was (Author: olamy): fixed http://svn.apache.org/r1442345 PMD/CPD violation exclusions by class/issue --- Key: MPMD-161 URL: https://jira.codehaus.org/browse/MPMD-161 Project: Maven 2.x PMD Plugin Issue Type: New Feature Components: CPD, PMD Reporter: Andrey Utis Assignee: Olivier Lamy Fix For: 3.0 Attachments: pmd2.7.1_exclusions2.patch, pmd_exclude_trunk.patch, pmd_exclude_trunk_v2.patch I work on a system that has a lot of legacy code with a lot of PMD/CPD violations. Introducing PMD to the build is not an easy option, since the build would always fail. So the next best thing is to exclude any existing violations and only fail if a new violation is introduced. Unfortunately, if I have thousands of violations, PMD doesn't provide a good way to do this. I'd have to add comments or annotations to all these places to ignore the violation. We came up with an alternative solution to this. We modified the PMD plugin to read a properties file that contains a mapping of class name to a list of excluded violations. If a particular violation is in this file, it does not cause the build to fail. Similar idea for CPD. An svn patch is attached (apply to 2.7.1) (Disclaimer: this is probably not the most elegant piece of code but it works and it was quick. Feel free to re-factor and make it more in line with the rest of the plugin code) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPMD-161) PMD/CPD violation exclusions by class/issue
[ https://jira.codehaus.org/browse/MPMD-161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MPMD-161. - Resolution: Fixed fixed http://svn.apache.org/r1442345 PMD/CPD violation exclusions by class/issue --- Key: MPMD-161 URL: https://jira.codehaus.org/browse/MPMD-161 Project: Maven 2.x PMD Plugin Issue Type: New Feature Components: CPD, PMD Reporter: Andrey Utis Assignee: Olivier Lamy Fix For: 3.0 Attachments: pmd2.7.1_exclusions2.patch, pmd_exclude_trunk.patch, pmd_exclude_trunk_v2.patch I work on a system that has a lot of legacy code with a lot of PMD/CPD violations. Introducing PMD to the build is not an easy option, since the build would always fail. So the next best thing is to exclude any existing violations and only fail if a new violation is introduced. Unfortunately, if I have thousands of violations, PMD doesn't provide a good way to do this. I'd have to add comments or annotations to all these places to ignore the violation. We came up with an alternative solution to this. We modified the PMD plugin to read a properties file that contains a mapping of class name to a list of excluded violations. If a particular violation is in this file, it does not cause the build to fail. Similar idea for CPD. An svn patch is attached (apply to 2.7.1) (Disclaimer: this is probably not the most elegant piece of code but it works and it was quick. Feel free to re-factor and make it more in line with the rest of the plugin code) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPH-31) medium mode should include plugin descriptions
[ https://jira.codehaus.org/browse/MPH-31?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MPH-31: -- Component/s: describe medium mode should include plugin descriptions -- Key: MPH-31 URL: https://jira.codehaus.org/browse/MPH-31 Project: Maven 2.x Help Plugin Issue Type: Bug Components: describe Reporter: Dan Fabulich Fix For: Backlog Run mvn help:describe -Dplugin=compiler -Dmojo=compile. You'll get this: [INFO] Mojo: 'compiler:compile' === Goal: 'compile' Description: Compiles application sources === Try again with mvn help:describe -Dplugin=compiler -Dmojo=compile -Dmedium. You'll get the exact same information. Try again with -Dfull. You'll get a highly verbose description of every parameter, including their type, required, readonly, and description. -Dmedium should include an in-between amount of information. I might suggest that it include all parameters by name and the description, but not type/required/readonly. (Perhaps omit readonly parameters from -Dmedium view?) We might also consider using only the first sentence of the description, just like Javadoc. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPH-45) Active profiles repeated each time for all projects in reactor
[ https://jira.codehaus.org/browse/MPH-45?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MPH-45: -- Component/s: all-profiles Active profiles repeated each time for all projects in reactor -- Key: MPH-45 URL: https://jira.codehaus.org/browse/MPH-45 Project: Maven 2.x Help Plugin Issue Type: Improvement Components: all-profiles Reporter: Sander Verhagen Attachments: MPH-45.diff Running the active-profiles goal in a multi-module project (with subsequently more than one project in the reactor) will all the active profiles for all the projects in the reactor, repeating this for every single project that is built, resulting in exhaustive output. Given that each showing of active profiles of a single project costs about eight lines in output (including some whitelines; that's with only one profile active), and us (over here) having 73 projects in the reactor, that's (73-1)*(73-1)*8 output lines being wasted. That's a silly 41472 lines for a simple mvn install. Well, I suppose an even simpler mvn clean will do the same ;-) And now I'm not even getting started about the fact that these 73 projects all share the same profile that they get from their top parent project. Over here we have a custom maven-help-plugin version running that shows the active profiles of every project in the reactor *only once*. I made the assumption that profiles are not going to change during the coarse of a single Maven execution. Is this a patch that we would be generally interested in? Or is this perhaps a bug in the inheritence behaviour of the plugin? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPH-78) effective-pom creates invalid xml because it outputs the Resource.mergeId
[
https://jira.codehaus.org/browse/MPH-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MPH-78:
--
Component/s: effective-pom
effective-pom creates invalid xml because it outputs the Resource.mergeId
-
Key: MPH-78
URL: https://jira.codehaus.org/browse/MPH-78
Project: Maven 2.x Help Plugin
Issue Type: Bug
Components: effective-pom
Affects Versions: 2.1.1
Reporter: Jacob Robertson
Priority: Minor
My organization would like to use the output from the effective-pom goal as
part of the deployed meta data in an ear. This is useful for some of our
scripting that needs properties and dependencyManagement versions resolved
(i.e. from parent poms), and the pom that is currently put in the ear does
not have that information. However, once we start generating the
effective-pom.xml file, any tool that uses xml validation will notice that
the mergeId tag is invalid. This is especially annoying in eclipse, as it
marks the whole project as having an error due to the effective-pom.xml file
being in the target directory under the eclipse project. We can of course
turn the xml validation off for the eclipse project or folder, but this is
one additional step to ask a multitude of developers to take in configuring
their projects.
I notice that the EffectivePomMojo class has a cleanModel method that
appears to sort the properties. Just to play with this, I added a
cleanResources method that calls Resource.setMergeId(null). This technique
does in fact work as I hoped for outputting the xml without the mergeId, but
it requires upgrading this plugin to use at least Maven 2.0.10.
{code}
private static void cleanModel( Model pom )
{
Properties properties = new SortedProperties();
properties.putAll( pom.getProperties() );
pom.setProperties( properties );
cleanResources( pom.getBuild().getResources() );
cleanResources( pom.getBuild().getTestResources() );
}
private static void cleanResources( List resources )
{
for ( Iterator i = resources.iterator(); i.hasNext(); )
{
Resource resource = (Resource) i.next();
resource.setMergeId( null );
}
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPH-86) Hide passwords for effective-pom
[
https://jira.codehaus.org/browse/MPH-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MPH-86:
--
Component/s: effective-pom
Hide passwords for effective-pom
Key: MPH-86
URL: https://jira.codehaus.org/browse/MPH-86
Project: Maven 2.x Help Plugin
Issue Type: Bug
Components: effective-pom
Affects Versions: 2.1.1
Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100)
Maven home: C:\Program Files (x86)\RscApplications\Maven3\bin\..
Java version: 1.6.0, vendor: IBM Corporation
Java home: C:\programs\ejbdeploy_base_v7\java\jre
Default locale: de_DE, platform encoding: Cp1252
OS name: windows 7, version: 6.1 build 7601 service pack 1, arch: x86,
family: windows
Reporter: Stefan Cordes
Executing
{{mvn help:effective-pom -Doutput=pom-effective.txt}}
with
{code:xml}
profiles
profile
iddefault/id
activation
activeByDefaulttrue/activeByDefault
/activation
properties
maven.scm.usernameMyUserId/maven.scm.username
maven.scm.passwordMyVerySecretPassword/maven.scm.password
/properties
/profile
/profiles
/settings
{code}
in
{{%userprofile%\.m2\settings.xml}}
results in an pom-effective.txt
which contains
{code:xml}
properties
maven.scm.usernameMyUserId/maven.scm.username
maven.scm.passwordMyVerySecretPassword/maven.scm.password
/properties
{code}
As (in our case) the pom-effective.txt should be checked in version control
system for later debug support we strongly need to hide the password analog
to
MPH-44 Hide passwords for effective-settings:
{code:xml}
properties
maven.scm.usernameMyUserId/maven.scm.username
maven.scm.password***/maven.scm.password
/properties
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPH-83) all-profiles should list profiles from settings.xml even if there is no project
[ https://jira.codehaus.org/browse/MPH-83?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MPH-83: -- Component/s: all-profiles all-profiles should list profiles from settings.xml even if there is no project --- Key: MPH-83 URL: https://jira.codehaus.org/browse/MPH-83 Project: Maven 2.x Help Plugin Issue Type: Bug Components: all-profiles Affects Versions: 2.1.1 Reporter: Julien Nicoulaud Running the goal all-profiles somewhere outside of a project answers No profile detected !. I have active and inactive profiles in my settings.xml, they should appear. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPH-53) mvn help:describe returns the version that is specified in metadata instead of the one in the parent pom
[
https://jira.codehaus.org/browse/MPH-53?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MPH-53:
--
Component/s: describe
Description:
{{mvn help:describe}} returns a different version than {{mvn
help:effective-pom}} returns:
{noformat}
mvn help:describe -Dplugin=surefire
...
[INFO] [help:describe]
[INFO] Plugin: 'org.apache.maven.plugins:maven-surefire-plugin:2.2'
---
Group Id: org.apache.maven.plugins
Artifact Id: maven-surefire-plugin
Version: 2.2
Goal Prefix: surefire
{noformat}
However, when I run {{mvn help:effective-pom}}
I get
{code:xml}
...
pluginManagement
plugins
plugin
artifactIdmaven-surefire-plugin/artifactId
version2.4.3/version
configuration
testFailureIgnoretrue/testFailureIgnore
includes
include**/*Test.java/include
/includes
formathtml/format
/configuration
/plugin
/plugins
/pluginManagement
...
{code}
My pom structure is quite simple: just a parent {{pom.xml}} with the
pluginmanagement section as above and a child pom using that. I have tested
with both maven 2.0.8 and 2.0.9.
See the discussion here:
http://www.nabble.com/Wrong-output-of-mvn-help%3Adescribe--td19168212.html
was:
mvn help:describe returns a different version than mvn help:effective-pom
returns:
mvn help:describe -Dplugin=surefire
...
[INFO] [help:describe]
[INFO] Plugin: 'org.apache.maven.plugins:maven-surefire-plugin:2.2'
---
Group Id: org.apache.maven.plugins
Artifact Id: maven-surefire-plugin
Version: 2.2
Goal Prefix: surefire
However, when I run:
mvn help:effective-pom
I get
...
pluginManagement
plugins
plugin
artifactIdmaven-surefire-plugin/artifactId
version2.4.3/version
configuration
testFailureIgnoretrue/testFailureIgnore
includes
include**/*Test.java/include
/includes
formathtml/format
/configuration
/plugin
/plugins
/pluginManagement
...
My pom structure is quite simple: just a parent pom.xml with the
pluginmanagement section as above and a child pom using that. I have tested
with both maven 2.0.8 and 2.0.9.
See the discussion here:
http://www.nabble.com/Wrong-output-of-mvn-help%3Adescribe--td19168212.html
mvn help:describe returns the version that is specified in metadata instead
of the one in the parent pom
-
Key: MPH-53
URL: https://jira.codehaus.org/browse/MPH-53
Project: Maven 2.x Help Plugin
Issue Type: Bug
Components: describe
Affects Versions: 2.0.1
Environment: windows xp
tested with mvn 2.0.8 2.0.9
Reporter: Rintcius Blok
Fix For: Backlog
{{mvn help:describe}} returns a different version than {{mvn
help:effective-pom}} returns:
{noformat}
mvn help:describe -Dplugin=surefire
...
[INFO] [help:describe]
[INFO] Plugin: 'org.apache.maven.plugins:maven-surefire-plugin:2.2'
---
Group Id: org.apache.maven.plugins
Artifact Id: maven-surefire-plugin
Version: 2.2
Goal Prefix: surefire
{noformat}
However, when I run {{mvn help:effective-pom}}
I get
{code:xml}
...
pluginManagement
plugins
plugin
artifactIdmaven-surefire-plugin/artifactId
version2.4.3/version
configuration
testFailureIgnoretrue/testFailureIgnore
includes
include**/*Test.java/include
/includes
formathtml/format
/configuration
/plugin
/plugins
/pluginManagement
...
{code}
My pom structure is quite simple: just a parent {{pom.xml}} with the
pluginmanagement section as above and a child pom using that. I have tested
with both maven 2.0.8 and 2.0.9.
See the discussion here:
http://www.nabble.com/Wrong-output-of-mvn-help%3Adescribe--td19168212.html
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
