[jira] (MSITE-669) site:stage creates incorrect structure when module paths contains sets of "../"
[ https://jira.codehaus.org/browse/MSITE-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=320037#comment-320037 ] Lennart Jorelid commented on MSITE-669: --- Taking a look at the site:stage-deploy goal, I am a little confused over its structure. One could assume that it would be relying on the fact that site:stage had been run, but instead it basically is a copy of the site:stage plus some extra steps/parameters to deploy the staged site. I wonder if it would not be more natural that the site:stage-deploy goal would # Need the site:stage goal to be run, and complain otherwise # Simply deploy the output from the site:stage goal to a remote location instead of doing all site:stage work all over again > site:stage creates incorrect structure when module paths contains sets of > "../" > --- > > Key: MSITE-669 > URL: https://jira.codehaus.org/browse/MSITE-669 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: Bug > Components: multi module, relative links, site:stage(-deploy) >Affects Versions: 3.1, 3.2 >Reporter: Lennart Jorelid >Assignee: Lukas Theussl > Attachments: msite_669.patch, msite_669_v2.patch, msite_669_v3.patch, > nazgul_tools_project_dependencies.png, nazgul_tools_project_dependencies.png, > nazgul_tools_reactor_structure.png, sample.zip > > > Given the module definitions given below, the site:stage goal produces sets > of maps relative to the staging directory - i.e. outside of the target > directory. > {code:xml} > > ../../validation/validation-api > ../../validation/validation-aspect > ../parent > > {code} > The staged site should be fully included within the staging directory. It > would appear that relativization of links for site:stage should take special > links into consideration. -- 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] (MCHANGES-304) Include an HTML announcement template
Alex Halovanic created MCHANGES-304: --- Summary: Include an HTML announcement template Key: MCHANGES-304 URL: https://jira.codehaus.org/browse/MCHANGES-304 Project: Maven 2.x Changes Plugin Issue Type: Improvement Components: announcement Reporter: Alex Halovanic Priority: Trivial Attachments: announcement_html.vm I'm pretty sure this has been brought up before, but is there interest in including an HTML version of the announcement email velocity template as an alternative to the default plaintext one? I've attached the one I've been using for a year or two here. It's my best attempt to emulate the appearance of the project report page with velocity. For others like me, it would eliminate having to unpack another dependency to make the email look more like the report page. -- 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-5435) Project which has shared dependency with a plugin fails to recognize artifact was downloaded and fails.
[ https://jira.codehaus.org/browse/MNG-5435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=320034#comment-320034 ] Kirk Rasmussen commented on MNG-5435: - And of course running it a second time it works fine. > Project which has shared dependency with a plugin fails to recognize artifact > was downloaded and fails. > --- > > Key: MNG-5435 > URL: https://jira.codehaus.org/browse/MNG-5435 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Artifacts and Repositories, Dependencies >Affects Versions: 3.0.4 >Reporter: Kirk Rasmussen >Priority: Blocker > Attachments: maven2.log, maven.log, pom.xml, settings.xml, simple.zip > > > This is a twofer bug report :) > Issue #1: > I have included a stripped down version of an example using the maven antrun > plugin to spawn the Antlr tool. For technical reasons we cannot use the > native maven Antlr plugin. > If you look at the attached project you will see that Antlr is a dependency > of both the antrun plugin: > {code} > ... > > > > org.apache.maven.plugins > maven-antrun-plugin > > > org.antlr > antlr > ${antlr.version} > > ... > {code} > And the project itself: > {code} > ... > > > org.antlr > antlr > > > ... > {code} > Starting with a blank M2 local repo, and then running > $ mvn -e -X -U clean install -s settings.xml > /tmp/maven.log > Results in failure: > Caused by: org.sonatype.aether.transfer.ArtifactNotFoundException: Could not > find artifact org.antlr:antlr:jar:3.4 > However this artifact was indeed downloaded (first as a project dependency). > I stepped through some of the Maven code and it appears to fail during the > second run through > org.sonatype.aether.impl.internal.DefaultArtifactResolver#resolve as a plugin > dependency. > I strongly suspect it has to do with how > org.sonatype.aether.impl.internal.EnhancedLocalRepositoryManager#find is > implemented. It sees the file but it is not being tracked correctly I believe > so it ignores it. > If you run the build a second time it will then succeed because the Antlr > artifacts will be available as they are in the local repo from the previous > run. > $ mvn -e -X -U clean install -s settings.xml > /tmp/maven2.log > I observed the exact same problem when using the Maven enforcer plugin along > with TestNG as they both depend on beanshell and with the Maven GWT plugin > and GWT project dependencies. > This was discovered as an issue once we started clearing out our local repo. > Once the artifacts are populated locally the issue goes away. It takes a > couple of runs to get past the bogus "missing artifact" errors but after that > it is ok. It's difficult to predict when it will fail w/o being intimately > familiar with all plugin/project dependencies per project. > I noticed that having Antlr 3.0.4 only as plugin dependency works fine. It > also works fine if it's only a project dependency. It's the combination of > having it both as a plugin AND a project dependency causes this problem. > #2 > My first thought to get around issue #1 was to use dependency:resolve as a > pre-build step after cleaning the local repo but that doesn't full solve the > problem. > Using the Mavan dependency:resolve and dependency:resolve-plugins goals > partially sidesteps issue #1 but it still gets confused about inter-module > dependencies. > For example I have a simple multi-module project that includes: foo-module, > bar-module, and baz-module (see simple.zip). > Running: > $ mvn dependency:resolve dependency:resolve-plugins -s settings.xml > Results in a build failure on the baz-module: > [INFO] acme-pom .. SUCCESS [6.835s] > [INFO] foo-module SUCCESS [1.327s] > [INFO] bar-module SUCCESS [0.090s] > [INFO] baz-module FAILURE [0.012s] > This seems to avoid issue #1 as it doesn't complain about missing Antlr > artifacts anymore but it gets stuck on the baz-module with the error: > [ERROR] Failed to execute goal on project baz-module: Could not resolve > dependencies for project com.acme:baz-module:jar:4.0.0-SNAPSHOT: The > following artifacts could not be resolved: > com.acme:foo-module:jar:4.0.0-SNAPSHOT, > com.acme:bar-module:jar:4.0.0-SNAPSHOT: Could not find artifact > com.acme:foo-module:jar:4.0.0-SNAPSHOT -> [Help 1] > In our real projects there are many more modules which don't get resolved > after this first failure so the local repo becomes only partial
[jira] (MNG-5435) Project which has shared dependency with a plugin fails to recognize artifact was downloaded and fails.
[ https://jira.codehaus.org/browse/MNG-5435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=320033#comment-320033 ] Kirk Rasmussen commented on MNG-5435: - Ugh it gets even worse. My next idea was to have a simple stand alone project which contained the problematic artifacts that we needed to be installed before running the real build. Running the following project with a blank repo: {code} $ mvn -e dependency:resolve {code} results in {code} Caused by: org.sonatype.aether.transfer.ArtifactNotFoundException: Could not find artifact commons-cli:commons-cli:jar:1.0 at org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:528) {code} It doesn't get much simpler than this: {code} http://maven.apache.org/POM/4.0.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd";> 4.0.0 com.textura.cpms continuous-integration 2.7.0-SNAPSHOT pom Continuous Integration Build Support org.apache.maven.plugins maven-enforcer-plugin 1.1.1 {code} > Project which has shared dependency with a plugin fails to recognize artifact > was downloaded and fails. > --- > > Key: MNG-5435 > URL: https://jira.codehaus.org/browse/MNG-5435 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Artifacts and Repositories, Dependencies >Affects Versions: 3.0.4 >Reporter: Kirk Rasmussen >Priority: Blocker > Attachments: maven2.log, maven.log, pom.xml, settings.xml, simple.zip > > > This is a twofer bug report :) > Issue #1: > I have included a stripped down version of an example using the maven antrun > plugin to spawn the Antlr tool. For technical reasons we cannot use the > native maven Antlr plugin. > If you look at the attached project you will see that Antlr is a dependency > of both the antrun plugin: > {code} > ... > > > > org.apache.maven.plugins > maven-antrun-plugin > > > org.antlr > antlr > ${antlr.version} > > ... > {code} > And the project itself: > {code} > ... > > > org.antlr > antlr > > > ... > {code} > Starting with a blank M2 local repo, and then running > $ mvn -e -X -U clean install -s settings.xml > /tmp/maven.log > Results in failure: > Caused by: org.sonatype.aether.transfer.ArtifactNotFoundException: Could not > find artifact org.antlr:antlr:jar:3.4 > However this artifact was indeed downloaded (first as a project dependency). > I stepped through some of the Maven code and it appears to fail during the > second run through > org.sonatype.aether.impl.internal.DefaultArtifactResolver#resolve as a plugin > dependency. > I strongly suspect it has to do with how > org.sonatype.aether.impl.internal.EnhancedLocalRepositoryManager#find is > implemented. It sees the file but it is not being tracked correctly I believe > so it ignores it. > If you run the build a second time it will then succeed because the Antlr > artifacts will be available as they are in the local repo from the previous > run. > $ mvn -e -X -U clean install -s settings.xml > /tmp/maven2.log > I observed the exact same problem when using the Maven enforcer plugin along > with TestNG as they both depend on beanshell and with the Maven GWT plugin > and GWT project dependencies. > This was discovered as an issue once we started clearing out our local repo. > Once the artifacts are populated locally the issue goes away. It takes a > couple of runs to get past the bogus "missing artifact" errors but after that > it is ok. It's difficult to predict when it will fail w/o being intimately > familiar with all plugin/project dependencies per project. > I noticed that having Antlr 3.0.4 only as plugin dependency works fine. It > also works fine if it's only a project dependency. It's the combination of > having it both as a plugin AND a project dependency causes this problem. > #2 > My first thought to get around issue #1 was to use dependency:resolve as a > pre-build step after cleaning the local repo but that doesn't full solve the > problem. > Using the Mavan dependency:resolve and dependency:resolve-plugins goals > partially sidesteps issue #1 but it still gets confused about inter-module > dependencies. > For example I have a simple multi-module project that includes: foo-module, > bar-module, and baz-module (see simple
[jira] (MNG-5435) Project which has shared dependency with a plugin fails to recognize artifact was downloaded and fails.
Kirk Rasmussen created MNG-5435: --- Summary: Project which has shared dependency with a plugin fails to recognize artifact was downloaded and fails. Key: MNG-5435 URL: https://jira.codehaus.org/browse/MNG-5435 Project: Maven 2 & 3 Issue Type: Bug Components: Artifacts and Repositories, Dependencies Affects Versions: 3.0.4 Reporter: Kirk Rasmussen Priority: Blocker Attachments: maven2.log, maven.log, pom.xml, settings.xml, simple.zip This is a twofer bug report :) Issue #1: I have included a stripped down version of an example using the maven antrun plugin to spawn the Antlr tool. For technical reasons we cannot use the native maven Antlr plugin. If you look at the attached project you will see that Antlr is a dependency of both the antrun plugin: {code} ... org.apache.maven.plugins maven-antrun-plugin org.antlr antlr ${antlr.version} ... {code} And the project itself: {code} ... org.antlr antlr ... {code} Starting with a blank M2 local repo, and then running $ mvn -e -X -U clean install -s settings.xml > /tmp/maven.log Results in failure: Caused by: org.sonatype.aether.transfer.ArtifactNotFoundException: Could not find artifact org.antlr:antlr:jar:3.4 However this artifact was indeed downloaded (first as a project dependency). I stepped through some of the Maven code and it appears to fail during the second run through org.sonatype.aether.impl.internal.DefaultArtifactResolver#resolve as a plugin dependency. I strongly suspect it has to do with how org.sonatype.aether.impl.internal.EnhancedLocalRepositoryManager#find is implemented. It sees the file but it is not being tracked correctly I believe so it ignores it. If you run the build a second time it will then succeed because the Antlr artifacts will be available as they are in the local repo from the previous run. $ mvn -e -X -U clean install -s settings.xml > /tmp/maven2.log I observed the exact same problem when using the Maven enforcer plugin along with TestNG as they both depend on beanshell and with the Maven GWT plugin and GWT project dependencies. This was discovered as an issue once we started clearing out our local repo. Once the artifacts are populated locally the issue goes away. It takes a couple of runs to get past the bogus "missing artifact" errors but after that it is ok. It's difficult to predict when it will fail w/o being intimately familiar with all plugin/project dependencies per project. I noticed that having Antlr 3.0.4 only as plugin dependency works fine. It also works fine if it's only a project dependency. It's the combination of having it both as a plugin AND a project dependency causes this problem. #2 My first thought to get around issue #1 was to use dependency:resolve as a pre-build step after cleaning the local repo but that doesn't full solve the problem. Using the Mavan dependency:resolve and dependency:resolve-plugins goals partially sidesteps issue #1 but it still gets confused about inter-module dependencies. For example I have a simple multi-module project that includes: foo-module, bar-module, and baz-module (see simple.zip). Running: $ mvn dependency:resolve dependency:resolve-plugins -s settings.xml Results in a build failure on the baz-module: [INFO] acme-pom .. SUCCESS [6.835s] [INFO] foo-module SUCCESS [1.327s] [INFO] bar-module SUCCESS [0.090s] [INFO] baz-module FAILURE [0.012s] This seems to avoid issue #1 as it doesn't complain about missing Antlr artifacts anymore but it gets stuck on the baz-module with the error: [ERROR] Failed to execute goal on project baz-module: Could not resolve dependencies for project com.acme:baz-module:jar:4.0.0-SNAPSHOT: The following artifacts could not be resolved: com.acme:foo-module:jar:4.0.0-SNAPSHOT, com.acme:bar-module:jar:4.0.0-SNAPSHOT: Could not find artifact com.acme:foo-module:jar:4.0.0-SNAPSHOT -> [Help 1] In our real projects there are many more modules which don't get resolved after this first failure so the local repo becomes only partially populated. -- 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-194) Strange effects with springs @Configurable (AspectJ) and new compiler plugin version 3.0
[ https://jira.codehaus.org/browse/MCOMPILER-194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=320019#comment-320019 ] Olivier Lamy commented on MCOMPILER-194: Does it happen with 3.1-SNAPSHOT ? And if configuring true ? Any test project ? > Strange effects with springs @Configurable (AspectJ) and new compiler plugin > version 3.0 > > > Key: MCOMPILER-194 > URL: https://jira.codehaus.org/browse/MCOMPILER-194 > Project: Maven 2.x Compiler Plugin > Issue Type: Bug >Affects Versions: 3.0 > Environment: jdk 1.6.0_38, jdk 1.6.0_37 >Reporter: Andreas Höhmann >Priority: Blocker > > I have no details I can only report the "effects" .. > I have a maven project with compiler-plugin 2.5.1, > aspectj-plugin 1.4, java 1.6 and a lot of @Configurable > annotations in my code. Aspectj will decorate these classes > so @Autowired dependencies injected during runtime. > All is working fine. > Now I switch to compiler-plugin 3.0 ... nothing else changed! > Then "sometimes" I got NPE's because the injected service etc. are > not available. I guess aspectj was not successfull. I have no > errors etc. anywhere during build. > Strang :) -- 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] (MSKINS-75) Add Piwik web analytics tracking code integration to Fluido skin
[ https://jira.codehaus.org/browse/MSKINS-75?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=320018#comment-320018 ] Olivier Lamy commented on MSKINS-75: good catch. Just fixed. Thanks! > Add Piwik web analytics tracking code integration to Fluido skin > > > Key: MSKINS-75 > URL: https://jira.codehaus.org/browse/MSKINS-75 > Project: Maven Skins > Issue Type: New Feature > Components: Fluido Skin >Reporter: Michael Koch >Assignee: Olivier Lamy >Priority: Minor > Fix For: fluido-1.3.1 > > Attachments: mskins-75.patch > > > I'd like to have support for adding the [Piwik web > analytics|http://piwik.org/] [tracking > code|http://piwik.org/docs/javascript-tracking/#toc-where-can-i-find-the-piwik-tracking-code] > for the Fluido skin. This is similar to the Google analytics code or > MSKINS-33. -- 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] (MSKINS-76) Add Flattr button integration to Fluido skin
[ https://jira.codehaus.org/browse/MSKINS-76?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=320010#comment-320010 ] Michael Koch commented on MSKINS-76: I am currently working on a patch for this and should have it ready in a few days. I'll attach it then. > Add Flattr button integration to Fluido skin > > > Key: MSKINS-76 > URL: https://jira.codehaus.org/browse/MSKINS-76 > Project: Maven Skins > Issue Type: New Feature > Components: Fluido Skin >Reporter: Michael Koch >Priority: Minor > > [Flattr|https://flattr.com/about] is a social micro-payment service. The > Flattr button works similar to the Google+ button. I'd like to have support > for adding a Flattr button in the Fluido skin. -- 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] (MSKINS-76) Add Flattr button integration to Fluido skin
Michael Koch created MSKINS-76: -- Summary: Add Flattr button integration to Fluido skin Key: MSKINS-76 URL: https://jira.codehaus.org/browse/MSKINS-76 Project: Maven Skins Issue Type: New Feature Components: Fluido Skin Reporter: Michael Koch Priority: Minor [Flattr|https://flattr.com/about] is a social micro-payment service. The Flattr button works similar to the Google+ button. I'd like to have support for adding a Flattr button in the Fluido skin. -- 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:comment-tabpanel&focusedCommentId=320009#comment-320009 ] Stuart McCulloch edited comment on MNG-5430 at 2/19/13 12:48 PM: - In case anyone wonders what exactly was fixed in Wagon 2.4: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10335&version=18697 was (Author: mcculls): In case anyone wonders what exactly was fixed in Wagon 2.4: http://jira.codehaus.org/browse/WAGON/fixforversion/18697 > 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, 3.1.0 > > -- 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:comment-tabpanel&focusedCommentId=320009#comment-320009 ] Stuart McCulloch commented on MNG-5430: --- In case anyone wonders what exactly was fixed in Wagon 2.4: http://jira.codehaus.org/browse/WAGON/fixforversion/18697 > 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, 3.1.0 > > -- 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] (MSKINS-75) Add Piwik web analytics tracking code integration to Fluido skin
[ https://jira.codehaus.org/browse/MSKINS-75?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=320008#comment-320008 ] Michael Koch commented on MSKINS-75: Thanks for accepting my patch. Please note that I wrote _"Since version <<1.4>>..."_ in _index.apt.vm_. You might want to change this if you release this in 1.3.1. > Add Piwik web analytics tracking code integration to Fluido skin > > > Key: MSKINS-75 > URL: https://jira.codehaus.org/browse/MSKINS-75 > Project: Maven Skins > Issue Type: New Feature > Components: Fluido Skin >Reporter: Michael Koch >Assignee: Olivier Lamy >Priority: Minor > Fix For: fluido-1.3.1 > > Attachments: mskins-75.patch > > > I'd like to have support for adding the [Piwik web > analytics|http://piwik.org/] [tracking > code|http://piwik.org/docs/javascript-tracking/#toc-where-can-i-find-the-piwik-tracking-code] > for the Fluido skin. This is similar to the Google analytics code or > MSKINS-33. -- 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-163) PMD issues are reported multiple times
[ https://jira.codehaus.org/browse/MPMD-163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MPMD-163. - Resolution: Fixed fixed http://svn.apache.org/r1447809 Thanks ! > PMD issues are reported multiple times > -- > > Key: MPMD-163 > URL: https://jira.codehaus.org/browse/MPMD-163 > Project: Maven 2.x PMD Plugin > Issue Type: Bug > Components: PMD >Affects Versions: 3.0 > Environment: Apache Maven 3.0.4 > Sun jdk1.6.0_04 on Debian Lenny > Oracle jdk 1.7.0_13 on Mac OS X (10.8.2) >Reporter: Mirko Friedenhagen >Assignee: Olivier Lamy >Priority: Blocker > Fix For: 3.1 > > Attachments: MPMD-163-against-tag-3.0.patch, my-app.zip > > > After updating maven-pmd-plugin from 2.7.1 to 3.0, in some of our projects > the number of pmd violations exploded. Some are valid (new rules), however I > have a project where the same violation will show up more than 70 times! > See below for an example of this dramatic outcome: > {code} > [mifr@host SomeService]$ grep '^ 3682 44655 1239557 > [mifr@host SomeService]$ grep '^ 921120 30832 > {code} > The number of source files in this project in total is 96, so a wild guess > would be, that the plugin readds already existing violations (the first > (unique) violation occurs once, the second 4 times and so on). I will try t > take a look at the source code or to get a working testcase. -- 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-163) PMD issues are reported multiple times
[ https://jira.codehaus.org/browse/MPMD-163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated MPMD-163: -- Fix Version/s: 3.1 Assignee: Olivier Lamy > PMD issues are reported multiple times > -- > > Key: MPMD-163 > URL: https://jira.codehaus.org/browse/MPMD-163 > Project: Maven 2.x PMD Plugin > Issue Type: Bug > Components: PMD >Affects Versions: 3.0 > Environment: Apache Maven 3.0.4 > Sun jdk1.6.0_04 on Debian Lenny > Oracle jdk 1.7.0_13 on Mac OS X (10.8.2) >Reporter: Mirko Friedenhagen >Assignee: Olivier Lamy >Priority: Blocker > Fix For: 3.1 > > Attachments: MPMD-163-against-tag-3.0.patch, my-app.zip > > > After updating maven-pmd-plugin from 2.7.1 to 3.0, in some of our projects > the number of pmd violations exploded. Some are valid (new rules), however I > have a project where the same violation will show up more than 70 times! > See below for an example of this dramatic outcome: > {code} > [mifr@host SomeService]$ grep '^ 3682 44655 1239557 > [mifr@host SomeService]$ grep '^ 921120 30832 > {code} > The number of source files in this project in total is 96, so a wild guess > would be, that the plugin readds already existing violations (the first > (unique) violation occurs once, the second 4 times and so on). I will try t > take a look at the source code or to get a working testcase. -- 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-3131) Error message is misleading if a missing plugin parameter is of a type like List
[ https://jira.codehaus.org/browse/MNG-3131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated MNG-3131: -- Fix Version/s: (was: 3.0.5) 3.1.0 > Error message is misleading if a missing plugin parameter is of a type like > List > > > Key: MNG-3131 > URL: https://jira.codehaus.org/browse/MNG-3131 > Project: Maven 2 & 3 > Issue Type: Bug >Reporter: Dennis Lundberg >Assignee: Robert Scholte > Fix For: 3.1.0 > > > Here is a sample output I got when I was working on the changes-plugin: > {code} > [INFO] One or more required plugin parameters are invalid/missing for > 'changes:announcement-mail' > [0] inside the definition for plugin: 'maven-changes-plugin'specify the > following: > > ... > VALUE > . > [1] inside the definition for plugin: 'maven-changes-plugin'specify the > following: > > ... > VALUE > . > {code} > Notice the second parameter toAdresses. It is of the type List, so the > correct configuration would be something like this > {code} > > ... > > VALUE > > . > {code} > I haven't found where in the code base the handling of List/Map/Array > parameters is. That code could probably be borrowed/reused in > maven-core/src/main/java/org/apache/maven/plugin/PluginParameterException.java > which is the class responsible for formating the above messages. -- 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-430) Clean up unused test files in src/test/projects/
Anders Hammar created ARCHETYPE-430: --- Summary: Clean up unused test files in src/test/projects/ Key: ARCHETYPE-430 URL: https://jira.codehaus.org/browse/ARCHETYPE-430 Project: Maven Archetype Issue Type: Task Components: Plugin Affects Versions: 2.2 Environment: n/a Reporter: Anders Hammar Priority: Minor There are some kind of unused tests in the src/test/projects folder. They should be removed/cleaned up. -- 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-74) Add packaging parameter
[ https://jira.codehaus.org/browse/ARCHETYPE-74?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anders Hammar closed ARCHETYPE-74. -- Resolution: Won't Fix The create goal is deprecated. Also, a parameter for the packaging doesn't make sense as that's very much part of the archetype. > Add packaging parameter > --- > > Key: ARCHETYPE-74 > URL: https://jira.codehaus.org/browse/ARCHETYPE-74 > Project: Maven Archetype > Issue Type: Wish > Components: Creator >Reporter: Jan Torben > > Hi, > I'd like to be able to select a parameter like -Dpackaging=war/pom/... at the > archetype:create command. > If you don't have time for that, I'd send you a patch. In that case, please > tell me how you like to get it. > Jan -- 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-163) PMD issues are reported multiple times
[ https://jira.codehaus.org/browse/MPMD-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=319988#comment-319988 ] Mirko Friedenhagen edited comment on MPMD-163 at 2/19/13 8:18 AM: -- Fix against https://svn.apache.org/repos/asf/maven/plugins/tags/maven-pmd-plugin-3.0, works against trunk as well, sorry for the svn:ignore. was (Author: mfriedenhagen): Fix against https://svn.apache.org/repos/asf/maven/plugins/tags/maven-pmd-plugin-3.0 > PMD issues are reported multiple times > -- > > Key: MPMD-163 > URL: https://jira.codehaus.org/browse/MPMD-163 > Project: Maven 2.x PMD Plugin > Issue Type: Bug > Components: PMD >Affects Versions: 3.0 > Environment: Apache Maven 3.0.4 > Sun jdk1.6.0_04 on Debian Lenny > Oracle jdk 1.7.0_13 on Mac OS X (10.8.2) >Reporter: Mirko Friedenhagen >Priority: Blocker > Attachments: MPMD-163-against-tag-3.0.patch, my-app.zip > > > After updating maven-pmd-plugin from 2.7.1 to 3.0, in some of our projects > the number of pmd violations exploded. Some are valid (new rules), however I > have a project where the same violation will show up more than 70 times! > See below for an example of this dramatic outcome: > {code} > [mifr@host SomeService]$ grep '^ 3682 44655 1239557 > [mifr@host SomeService]$ grep '^ 921120 30832 > {code} > The number of source files in this project in total is 96, so a wild guess > would be, that the plugin readds already existing violations (the first > (unique) violation occurs once, the second 4 times and so on). I will try t > take a look at the source code or to get a working testcase. -- 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-163) PMD issues are reported multiple times
[ https://jira.codehaus.org/browse/MPMD-163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mirko Friedenhagen updated MPMD-163: Attachment: MPMD-163-against-tag-3.0.patch Fix against https://svn.apache.org/repos/asf/maven/plugins/tags/maven-pmd-plugin-3.0 > PMD issues are reported multiple times > -- > > Key: MPMD-163 > URL: https://jira.codehaus.org/browse/MPMD-163 > Project: Maven 2.x PMD Plugin > Issue Type: Bug > Components: PMD >Affects Versions: 3.0 > Environment: Apache Maven 3.0.4 > Sun jdk1.6.0_04 on Debian Lenny > Oracle jdk 1.7.0_13 on Mac OS X (10.8.2) >Reporter: Mirko Friedenhagen >Priority: Blocker > Attachments: MPMD-163-against-tag-3.0.patch, my-app.zip > > > After updating maven-pmd-plugin from 2.7.1 to 3.0, in some of our projects > the number of pmd violations exploded. Some are valid (new rules), however I > have a project where the same violation will show up more than 70 times! > See below for an example of this dramatic outcome: > {code} > [mifr@host SomeService]$ grep '^ 3682 44655 1239557 > [mifr@host SomeService]$ grep '^ 921120 30832 > {code} > The number of source files in this project in total is 96, so a wild guess > would be, that the plugin readds already existing violations (the first > (unique) violation occurs once, the second 4 times and so on). I will try t > take a look at the source code or to get a working testcase. -- 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-163) PMD issues are reported multiple times
[ https://jira.codehaus.org/browse/MPMD-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=319984#comment-319984 ] Melloware commented on MPMD-163: I just upgraded to 3.0 this weekend and I am seeing the exact same error. Tons of duplicates reported repeatedly in the PMD output. > PMD issues are reported multiple times > -- > > Key: MPMD-163 > URL: https://jira.codehaus.org/browse/MPMD-163 > Project: Maven 2.x PMD Plugin > Issue Type: Bug > Components: PMD >Affects Versions: 3.0 > Environment: Apache Maven 3.0.4 > Sun jdk1.6.0_04 on Debian Lenny > Oracle jdk 1.7.0_13 on Mac OS X (10.8.2) >Reporter: Mirko Friedenhagen >Priority: Blocker > Attachments: my-app.zip > > > After updating maven-pmd-plugin from 2.7.1 to 3.0, in some of our projects > the number of pmd violations exploded. Some are valid (new rules), however I > have a project where the same violation will show up more than 70 times! > See below for an example of this dramatic outcome: > {code} > [mifr@host SomeService]$ grep '^ 3682 44655 1239557 > [mifr@host SomeService]$ grep '^ 921120 30832 > {code} > The number of source files in this project in total is 96, so a wild guess > would be, that the plugin readds already existing violations (the first > (unique) violation occurs once, the second 4 times and so on). I will try t > take a look at the source code or to get a working testcase. -- 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-163) PMD issues are reported multiple times
[ https://jira.codehaus.org/browse/MPMD-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=319978#comment-319978 ] Mirko Friedenhagen commented on MPMD-163: - When running the unit-tests, this shows as well: {code} Running org.apache.maven.plugin.pmd.PmdViolationCheckMojoTest [INFO] You have 17 warnings. For more details see:/Users/mifr/workspace/foss/maven-pmd-plugin-3.0/target/test/unit/default-configuration/target/pmd.xml [INFO] PMD Warning: def.configuration.App:80 Rule:UselessParentheses Priority:4 Useless parentheses.. [INFO] PMD Warning: def/configuration/App2.java:22 Rule:UnusedImports Priority:4 Avoid unused imports such as 'java.io.File'. [INFO] PMD Warning: def/configuration/App2.java:22 Rule:UnusedImports Priority:4 Avoid unused imports such as 'java.io.File'. [INFO] PMD Warning: def.configuration.AppSample:58 Rule:UselessParentheses Priority:4 Useless parentheses.. [INFO] PMD Warning: def.configuration.AppSample:58 Rule:UselessParentheses Priority:4 Useless parentheses.. [INFO] PMD Warning: def.configuration.AppSample:58 Rule:UselessParentheses Priority:4 Useless parentheses.. [INFO] PMD Failure: def.configuration.App:31 Rule:UnusedPrivateField Priority:3 Avoid unused private fields such as 'unusedVar2'.. [INFO] PMD Failure: def.configuration.App:56 Rule:EmptyCatchBlock Priority:3 Avoid empty catch blocks. [INFO] PMD Failure: def.configuration.AppSample:27 Rule:UnusedPrivateField Priority:3 Avoid unused private fields such as 'unusedVar'.. [INFO] PMD Failure: def.configuration.AppSample:27 Rule:UnusedPrivateField Priority:3 Avoid unused private fields such as 'unusedVar'.. [INFO] PMD Failure: def.configuration.AppSample:27 Rule:UnusedPrivateField Priority:3 Avoid unused private fields such as 'unusedVar'.. [INFO] PMD Failure: def.configuration.AppSample:45 Rule:UnusedFormalParameter Priority:3 Avoid unused method parameters such as 'unusedParam'.. [INFO] PMD Failure: def.configuration.AppSample:45 Rule:UnusedFormalParameter Priority:3 Avoid unused method parameters such as 'unusedParam'.. [INFO] PMD Failure: def.configuration.AppSample:45 Rule:UnusedFormalParameter Priority:3 Avoid unused method parameters such as 'unusedParam'.. [INFO] PMD Failure: def.configuration.AppSample:45 Rule:UnusedPrivateMethod Priority:3 Avoid unused private methods such as 'unusedMethod(String)'.. [INFO] PMD Failure: def.configuration.AppSample:45 Rule:UnusedPrivateMethod Priority:3 Avoid unused private methods such as 'unusedMethod(String)'.. [INFO] PMD Failure: def.configuration.AppSample:45 Rule:UnusedPrivateMethod Priority:3 Avoid unused private methods such as 'unusedMethod(String)'.. Caught Expected Message: You have 11 PMD violations and 6 warnings. For more details see:/Users/mifr/workspace/foss/maven-pmd-plugin-3.0/target/test/unit/default-configuration/target/pmd.xml {code} > PMD issues are reported multiple times > -- > > Key: MPMD-163 > URL: https://jira.codehaus.org/browse/MPMD-163 > Project: Maven 2.x PMD Plugin > Issue Type: Bug > Components: PMD >Affects Versions: 3.0 > Environment: Apache Maven 3.0.4 > Sun jdk1.6.0_04 on Debian Lenny > Oracle jdk 1.7.0_13 on Mac OS X (10.8.2) >Reporter: Mirko Friedenhagen >Priority: Blocker > Attachments: my-app.zip > > > After updating maven-pmd-plugin from 2.7.1 to 3.0, in some of our projects > the number of pmd violations exploded. Some are valid (new rules), however I > have a project where the same violation will show up more than 70 times! > See below for an example of this dramatic outcome: > {code} > [mifr@host SomeService]$ grep '^ 3682 44655 1239557 > [mifr@host SomeService]$ grep '^ 921120 30832 > {code} > The number of source files in this project in total is 96, so a wild guess > would be, that the plugin readds already existing violations (the first > (unique) violation occurs once, the second 4 times and so on). I will try t > take a look at the source code or to get a working testcase. -- 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-163) PMD issues are reported multiple times
[ https://jira.codehaus.org/browse/MPMD-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=319975#comment-319975 ] Reijo Tomperi edited comment on MPMD-163 at 2/19/13 6:24 AM: - I attached my-app.zip, which is a sample project where error occurs. It reports these two violations for othe same file: Avoid unused constructor parameters such as 'foo'. 4 Avoid unused constructor parameters such as 'foo'. 4 It should report this violation only once. If you remove App.java or rename the class (and file) e.g. to Gapp, then the duplicate goes away. This also causes outofmemory error in our project (requires more than 4 GB of memory because the report size grows so large. This renders the new version not only unusable to us, but we had to fall back to previous version (which was especially difficult, because the two versions use different paths in resultset configuration file. And to make things even worse, maven 2 uses the latest version if you use "mvn pmd:pmd", even if you have specified it to use some other version in the pom.xml. Only way to use different version is to use command 'mvn org.apache.maven.plugins:maven-pmd-plugin:2.4:pmd'. was (Author: dvice): I attached my-app.zip, which is a sample project where error occurs. It reports these two violations for othe same file: Avoid unused constructor parameters such as 'foo'. 4 Avoid unused constructor parameters such as 'foo'. 4 It should report this violation only once. If you remove App.java or rename the class e.g. to Gapp, then the duplicate goes away. > PMD issues are reported multiple times > -- > > Key: MPMD-163 > URL: https://jira.codehaus.org/browse/MPMD-163 > Project: Maven 2.x PMD Plugin > Issue Type: Bug > Components: PMD >Affects Versions: 3.0 > Environment: Apache Maven 3.0.4 > Sun jdk1.6.0_04 on Debian Lenny > Oracle jdk 1.7.0_13 on Mac OS X (10.8.2) >Reporter: Mirko Friedenhagen >Priority: Blocker > Attachments: my-app.zip > > > After updating maven-pmd-plugin from 2.7.1 to 3.0, in some of our projects > the number of pmd violations exploded. Some are valid (new rules), however I > have a project where the same violation will show up more than 70 times! > See below for an example of this dramatic outcome: > {code} > [mifr@host SomeService]$ grep '^ 3682 44655 1239557 > [mifr@host SomeService]$ grep '^ 921120 30832 > {code} > The number of source files in this project in total is 96, so a wild guess > would be, that the plugin readds already existing violations (the first > (unique) violation occurs once, the second 4 times and so on). I will try t > take a look at the source code or to get a working testcase. -- 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-163) PMD issues are reported multiple times
[ https://jira.codehaus.org/browse/MPMD-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=319975#comment-319975 ] Reijo Tomperi edited comment on MPMD-163 at 2/19/13 6:16 AM: - I attached my-app.zip, which is a sample project where error occurs. It reports these two violations for othe same file: Avoid unused constructor parameters such as 'foo'. 4 Avoid unused constructor parameters such as 'foo'. 4 It should report this violation only once. If you remove App.java or rename the class e.g. to Gapp, then the duplicate goes away. was (Author: dvice): Sample project where error occurs > PMD issues are reported multiple times > -- > > Key: MPMD-163 > URL: https://jira.codehaus.org/browse/MPMD-163 > Project: Maven 2.x PMD Plugin > Issue Type: Bug > Components: PMD >Affects Versions: 3.0 > Environment: Apache Maven 3.0.4 > Sun jdk1.6.0_04 on Debian Lenny > Oracle jdk 1.7.0_13 on Mac OS X (10.8.2) >Reporter: Mirko Friedenhagen >Priority: Blocker > Attachments: my-app.zip > > > After updating maven-pmd-plugin from 2.7.1 to 3.0, in some of our projects > the number of pmd violations exploded. Some are valid (new rules), however I > have a project where the same violation will show up more than 70 times! > See below for an example of this dramatic outcome: > {code} > [mifr@host SomeService]$ grep '^ 3682 44655 1239557 > [mifr@host SomeService]$ grep '^ 921120 30832 > {code} > The number of source files in this project in total is 96, so a wild guess > would be, that the plugin readds already existing violations (the first > (unique) violation occurs once, the second 4 times and so on). I will try t > take a look at the source code or to get a working testcase. -- 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-163) PMD issues are reported multiple times
[ https://jira.codehaus.org/browse/MPMD-163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Reijo Tomperi updated MPMD-163: --- Attachment: my-app.zip Sample project where error occurs > PMD issues are reported multiple times > -- > > Key: MPMD-163 > URL: https://jira.codehaus.org/browse/MPMD-163 > Project: Maven 2.x PMD Plugin > Issue Type: Bug > Components: PMD >Affects Versions: 3.0 > Environment: Apache Maven 3.0.4 > Sun jdk1.6.0_04 on Debian Lenny > Oracle jdk 1.7.0_13 on Mac OS X (10.8.2) >Reporter: Mirko Friedenhagen >Priority: Blocker > Attachments: my-app.zip > > > After updating maven-pmd-plugin from 2.7.1 to 3.0, in some of our projects > the number of pmd violations exploded. Some are valid (new rules), however I > have a project where the same violation will show up more than 70 times! > See below for an example of this dramatic outcome: > {code} > [mifr@host SomeService]$ grep '^ 3682 44655 1239557 > [mifr@host SomeService]$ grep '^ 921120 30832 > {code} > The number of source files in this project in total is 96, so a wild guess > would be, that the plugin readds already existing violations (the first > (unique) violation occurs once, the second 4 times and so on). I will try t > take a look at the source code or to get a working testcase. -- 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-163) PMD issues are reported multiple times
[ https://jira.codehaus.org/browse/MPMD-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=319973#comment-319973 ] Reijo Tomperi edited comment on MPMD-163 at 2/19/13 6:10 AM: - I see this problem also. You can see the duplicates if you create a project with two files in the same package A.java and B.java. If there is a violation in B.java, then it is reported twice. If the violation is in A.java, it gets reported only once. If you have A, B and C. Then violations in C are reported 3 times etc. Also files in other folders can affect this (but that gets more complicated to follow). I tested this with this file: import java.util.ArrayList; public class Foo { public Foo(final ArrayList foo) { } } Also note that I don't see this problem when using standalone PMD, so this seems to be issue in the PMD plugin itself. I'm using Apache Maven 2.2.1. was (Author: dvice): I see this problem also. You can see the duplicates if you create a project with two files in the same package A.java and B.java. If there is a violation in B.java, then it is reported twice. If the violation is in A.java, it gets reported only once. If you have A, B and C. Then violations in C are reported 3 times etc. Also files in other folders can affect this (but that gets more complicated to follow). I tested this with this file: import java.util.ArrayList; public class Foo { public Foo(final ArrayList foo) { } } Also note that I don't see this problem when using standalone PMD, so this seems to be issue in the PMD plugin itself. > PMD issues are reported multiple times > -- > > Key: MPMD-163 > URL: https://jira.codehaus.org/browse/MPMD-163 > Project: Maven 2.x PMD Plugin > Issue Type: Bug > Components: PMD >Affects Versions: 3.0 > Environment: Apache Maven 3.0.4 > Sun jdk1.6.0_04 on Debian Lenny > Oracle jdk 1.7.0_13 on Mac OS X (10.8.2) >Reporter: Mirko Friedenhagen >Priority: Blocker > > After updating maven-pmd-plugin from 2.7.1 to 3.0, in some of our projects > the number of pmd violations exploded. Some are valid (new rules), however I > have a project where the same violation will show up more than 70 times! > See below for an example of this dramatic outcome: > {code} > [mifr@host SomeService]$ grep '^ 3682 44655 1239557 > [mifr@host SomeService]$ grep '^ 921120 30832 > {code} > The number of source files in this project in total is 96, so a wild guess > would be, that the plugin readds already existing violations (the first > (unique) violation occurs once, the second 4 times and so on). I will try t > take a look at the source code or to get a working testcase. -- 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-163) PMD issues are reported multiple times
[ https://jira.codehaus.org/browse/MPMD-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=319973#comment-319973 ] Reijo Tomperi commented on MPMD-163: I see this problem also. You can see the duplicates if you create a project with two files in the same package A.java and B.java. If there is a violation in B.java, then it is reported twice. If the violation is in A.java, it gets reported only once. If you have A, B and C. Then violations in C are reported 3 times etc. Also files in other folders can affect this (but that gets more complicated to follow). I tested this with this file: import java.util.ArrayList; public class Foo { public Foo(final ArrayList foo) { } } Also note that I don't see this problem when using standalone PMD, so this seems to be issue in the PMD plugin itself. > PMD issues are reported multiple times > -- > > Key: MPMD-163 > URL: https://jira.codehaus.org/browse/MPMD-163 > Project: Maven 2.x PMD Plugin > Issue Type: Bug > Components: PMD >Affects Versions: 3.0 > Environment: Apache Maven 3.0.4 > Sun jdk1.6.0_04 on Debian Lenny > Oracle jdk 1.7.0_13 on Mac OS X (10.8.2) >Reporter: Mirko Friedenhagen >Priority: Blocker > > After updating maven-pmd-plugin from 2.7.1 to 3.0, in some of our projects > the number of pmd violations exploded. Some are valid (new rules), however I > have a project where the same violation will show up more than 70 times! > See below for an example of this dramatic outcome: > {code} > [mifr@host SomeService]$ grep '^ 3682 44655 1239557 > [mifr@host SomeService]$ grep '^ 921120 30832 > {code} > The number of source files in this project in total is 96, so a wild guess > would be, that the plugin readds already existing violations (the first > (unique) violation occurs once, the second 4 times and so on). I will try t > take a look at the source code or to get a working testcase. -- 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] (MSKINS-75) Add Piwik web analytics tracking code integration to Fluido skin
[ https://jira.codehaus.org/browse/MSKINS-75?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MSKINS-75. -- Resolution: Fixed fixed http://svn.apache.org/r1447677 > Add Piwik web analytics tracking code integration to Fluido skin > > > Key: MSKINS-75 > URL: https://jira.codehaus.org/browse/MSKINS-75 > Project: Maven Skins > Issue Type: New Feature > Components: Fluido Skin >Reporter: Michael Koch >Assignee: Olivier Lamy >Priority: Minor > Fix For: fluido-1.3.1 > > Attachments: mskins-75.patch > > > I'd like to have support for adding the [Piwik web > analytics|http://piwik.org/] [tracking > code|http://piwik.org/docs/javascript-tracking/#toc-where-can-i-find-the-piwik-tracking-code] > for the Fluido skin. This is similar to the Google analytics code or > MSKINS-33. -- 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] (MSKINS-75) Add Piwik web analytics tracking code integration to Fluido skin
[ https://jira.codehaus.org/browse/MSKINS-75?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated MSKINS-75: --- Fix Version/s: fluido-1.3.1 Assignee: Olivier Lamy > Add Piwik web analytics tracking code integration to Fluido skin > > > Key: MSKINS-75 > URL: https://jira.codehaus.org/browse/MSKINS-75 > Project: Maven Skins > Issue Type: New Feature > Components: Fluido Skin >Reporter: Michael Koch >Assignee: Olivier Lamy >Priority: Minor > Fix For: fluido-1.3.1 > > Attachments: mskins-75.patch > > > I'd like to have support for adding the [Piwik web > analytics|http://piwik.org/] [tracking > code|http://piwik.org/docs/javascript-tracking/#toc-where-can-i-find-the-piwik-tracking-code] > for the Fluido skin. This is similar to the Google analytics code or > MSKINS-33. -- 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-163) PMD issues are reported multiple times
Mirko Friedenhagen created MPMD-163: --- Summary: PMD issues are reported multiple times Key: MPMD-163 URL: https://jira.codehaus.org/browse/MPMD-163 Project: Maven 2.x PMD Plugin Issue Type: Bug Components: PMD Affects Versions: 3.0 Environment: Apache Maven 3.0.4 Sun jdk1.6.0_04 on Debian Lenny Oracle jdk 1.7.0_13 on Mac OS X (10.8.2) Reporter: Mirko Friedenhagen Priority: Blocker After updating maven-pmd-plugin from 2.7.1 to 3.0, in some of our projects the number of pmd violations exploded. Some are valid (new rules), however I have a project where the same violation will show up more than 70 times! See below for an example of this dramatic outcome: {code} [mifr@host SomeService]$ grep '^https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira