[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 '^violation' target/pmd.xml | wc
3682 44655 1239557
[mifr@host SomeService]$ grep '^violation' target/pmd.xml | sort | uniq | wc
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 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] (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] (MPMD-163) PMD issues are reported multiple times
[
https://jira.codehaus.org/browse/MPMD-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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 ArrayListString 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 '^violation' target/pmd.xml | wc
3682 44655 1239557
[mifr@host SomeService]$ grep '^violation' target/pmd.xml | sort | uniq | wc
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-tabpanelfocusedCommentId=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 ArrayListString 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 ArrayListString 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 '^violation' target/pmd.xml | wc
3682 44655 1239557
[mifr@host SomeService]$ grep '^violation' target/pmd.xml | sort | uniq | wc
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 '^violation' target/pmd.xml | wc
3682 44655 1239557
[mifr@host SomeService]$ grep '^violation' target/pmd.xml | sort | uniq | wc
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-tabpanelfocusedCommentId=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 '^violation' target/pmd.xml | wc
3682 44655 1239557
[mifr@host SomeService]$ grep '^violation' target/pmd.xml | sort | uniq | wc
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-tabpanelfocusedCommentId=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 '^violation' target/pmd.xml | wc
3682 44655 1239557
[mifr@host SomeService]$ grep '^violation' target/pmd.xml | sort | uniq | wc
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-tabpanelfocusedCommentId=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 '^violation' target/pmd.xml | wc
3682 44655 1239557
[mifr@host SomeService]$ grep '^violation' target/pmd.xml | sort | uniq | wc
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-tabpanelfocusedCommentId=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 '^violation' target/pmd.xml | wc
3682 44655 1239557
[mifr@host SomeService]$ grep '^violation' target/pmd.xml | sort | uniq | wc
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 '^violation' target/pmd.xml | wc
3682 44655 1239557
[mifr@host SomeService]$ grep '^violation' target/pmd.xml | sort | uniq | wc
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-tabpanelfocusedCommentId=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 '^violation' target/pmd.xml | wc
3682 44655 1239557
[mifr@host SomeService]$ grep '^violation' target/pmd.xml | sort | uniq | wc
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] (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] (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] (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:
configuration
...
smtpHostVALUE/smtpHost
/configuration.
[1] inside the definition for plugin: 'maven-changes-plugin'specify the
following:
configuration
...
toAddressesVALUE/toAddresses
/configuration.
{code}
Notice the second parameter toAdresses. It is of the type List, so the
correct configuration would be something like this
{code}
configuration
...
toAddresses
toAddressVALUE/toAddress
/toAddresses
/configuration.
{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] (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 '^violation' target/pmd.xml | wc
3682 44655 1239557
[mifr@host SomeService]$ grep '^violation' target/pmd.xml | sort | uniq | wc
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 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 '^violation' target/pmd.xml | wc
3682 44655 1239557
[mifr@host SomeService]$ grep '^violation' target/pmd.xml | sort | uniq | wc
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-5430) use wagon 2.4
[ https://jira.codehaus.org/browse/MNG-5430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-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-tabpanelfocusedCommentId=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=10335version=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] (MSKINS-76) Add Flattr button integration to Fluido skin
[ https://jira.codehaus.org/browse/MSKINS-76?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-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-tabpanelfocusedCommentId=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] (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-tabpanelfocusedCommentId=320019#comment-320019 ] Olivier Lamy commented on MCOMPILER-194: Does it happen with 3.1-SNAPSHOT ? And if configuring forceJavacCompilerUsetrue/forceJavacCompilerUse ? 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] (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}
...
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-antrun-plugin/artifactId
dependencies
dependency
groupIdorg.antlr/groupId
artifactIdantlr/artifactId
version${antlr.version}/version
/dependency
...
{code}
And the project itself:
{code}
...
dependencies
dependency
groupIdorg.antlr/groupId
artifactIdantlr/artifactId
/dependency
/dependencies
...
{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:
[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-tabpanelfocusedCommentId=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}
project xmlns=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;
modelVersion4.0.0/modelVersion
groupIdcom.textura.cpms/groupId
artifactIdcontinuous-integration/artifactId
version2.7.0-SNAPSHOT/version
packagingpom/packaging
nameContinuous Integration Build Support/name
dependencies
dependency
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-enforcer-plugin/artifactId
version1.1.1/version
/dependency
/dependencies
/project
{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}
...
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-antrun-plugin/artifactId
dependencies
dependency
groupIdorg.antlr/groupId
artifactIdantlr/artifactId
version${antlr.version}/version
/dependency
...
{code}
And the project itself:
{code}
...
dependencies
dependency
groupIdorg.antlr/groupId
artifactIdantlr/artifactId
/dependency
/dependencies
...
{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
[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-tabpanelfocusedCommentId=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}
...
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-antrun-plugin/artifactId
dependencies
dependency
groupIdorg.antlr/groupId
artifactIdantlr/artifactId
version${antlr.version}/version
/dependency
...
{code}
And the project itself:
{code}
...
dependencies
dependency
groupIdorg.antlr/groupId
artifactIdantlr/artifactId
/dependency
/dependencies
...
{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
[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] (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-tabpanelfocusedCommentId=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}
modules
module../../validation/validation-api/module
module../../validation/validation-aspect/module
module../parent/module
/modules
{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
