[jira] [Comment Edited] (SUREFIRE-1587) Forked execution prevents correct ServerSocket closing
[
https://issues.apache.org/jira/browse/SUREFIRE-1587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16674915#comment-16674915
]
Johannes Wienke edited comment on SUREFIRE-1587 at 11/5/18 10:18 AM:
-
Could you give me a hint how forking is done? I wanted to test this in
isolation without surefire involved, too, but I wasn't able to figure out how
the forking is implemented in surefire. Maybe I can rebuild that and repeat the
test. How does the forked test process communicate its reports back to the
parent?
was (Author: languitar):
Could you give me a hint how forking is done? I wanted to test this in
isolation without surefire involved, too, but I wasn't able to figure out how
the forking is implemented in surefire. Maybe I can rebuild that an repeat the
test again. How does the forked test process communicate its reports back to
the parent?
> Forked execution prevents correct ServerSocket closing
> --
>
> Key: SUREFIRE-1587
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1587
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 2.22.1
> Environment: Linux, problem becomes visible on archlinux and also on
> Travis CI
>Reporter: Johannes Wienke
>Assignee: Tibor Digana
>Priority: Major
>
> The default mode of forked unit test execution (with JUnit) seems to
> interfere with socket operations. In our case, we see that with a surefire
> execution in forked mode, ServerSocket instances, despite returning from a
> close() call, are sometimes not correctly closed and a subsequent try to
> acquire a server socket on the same port then fails. This does not happen
> outside of surefire or when forkMode is set to none.
> Here is a simple test case to try this. First the maven project pom.xml:
> {code:title=pom.xml|borderStyle=solid}
>
> 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
> testing
> testit
> 1.0-SNAPSHOT
> testit
> A simple testit.
> http://www.example.com
>
> UTF-8
> 1.7
> 1.7
>
>
>
> junit
> junit
> 4.11
> test
>
>
>
>
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.22.1
>
>
>
>
> {code}
> And here a test file to be placed into the test source tree:
> {code:title=AppTest.java|borderStyle=solid}
> package testing;
> import org.junit.Test;
> import java.net.ServerSocket;
> public class AppTest {
> @Test
> public void testSocketStuff() throws Exception {
> while (true) {
> System.out.println("Iteration");
> final ServerSocket socket = new ServerSocket(55444);
> socket.close();
> }
> }
> }
> {code}
> Executing this with the default options (forking mode enabled) will pretty
> soon end up in the following exception after some iterations:
> {code}
> [ERROR] testSocketStuff(testing.AppTest) Time elapsed: 1.376 s <<< ERROR!
> java.net.BindException: Address already in use (Bind failed)
> at testing.AppTest.testSocketStuff(AppTest.java:17)
> {code}
> Executing the same test with -DforkMode=none does not result in this failure
> and the loop runs endlessly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1587) Forked execution prevents correct ServerSocket closing
[
https://issues.apache.org/jira/browse/SUREFIRE-1587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16674915#comment-16674915
]
Johannes Wienke commented on SUREFIRE-1587:
---
Could you give me a hint how forking is done? I wanted to test this in
isolation without surefire involved, too, but I wasn't able to figure out how
the forking is implemented in surefire. Maybe I can rebuild that an repeat the
test again. How does the forked test process communicate its reports back to
the parent?
> Forked execution prevents correct ServerSocket closing
> --
>
> Key: SUREFIRE-1587
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1587
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 2.22.1
> Environment: Linux, problem becomes visible on archlinux and also on
> Travis CI
>Reporter: Johannes Wienke
>Assignee: Tibor Digana
>Priority: Major
>
> The default mode of forked unit test execution (with JUnit) seems to
> interfere with socket operations. In our case, we see that with a surefire
> execution in forked mode, ServerSocket instances, despite returning from a
> close() call, are sometimes not correctly closed and a subsequent try to
> acquire a server socket on the same port then fails. This does not happen
> outside of surefire or when forkMode is set to none.
> Here is a simple test case to try this. First the maven project pom.xml:
> {code:title=pom.xml|borderStyle=solid}
>
> 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
> testing
> testit
> 1.0-SNAPSHOT
> testit
> A simple testit.
> http://www.example.com
>
> UTF-8
> 1.7
> 1.7
>
>
>
> junit
> junit
> 4.11
> test
>
>
>
>
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.22.1
>
>
>
>
> {code}
> And here a test file to be placed into the test source tree:
> {code:title=AppTest.java|borderStyle=solid}
> package testing;
> import org.junit.Test;
> import java.net.ServerSocket;
> public class AppTest {
> @Test
> public void testSocketStuff() throws Exception {
> while (true) {
> System.out.println("Iteration");
> final ServerSocket socket = new ServerSocket(55444);
> socket.close();
> }
> }
> }
> {code}
> Executing this with the default options (forking mode enabled) will pretty
> soon end up in the following exception after some iterations:
> {code}
> [ERROR] testSocketStuff(testing.AppTest) Time elapsed: 1.376 s <<< ERROR!
> java.net.BindException: Address already in use (Bind failed)
> at testing.AppTest.testSocketStuff(AppTest.java:17)
> {code}
> Executing the same test with -DforkMode=none does not result in this failure
> and the loop runs endlessly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SUREFIRE-1587) Forked execution prevents correct ServerSocket closing
[
https://issues.apache.org/jira/browse/SUREFIRE-1587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Johannes Wienke updated SUREFIRE-1587:
--
Summary: Forked execution prevents correct ServerSocket closing (was:
Forked execution prevents correct ServerSocket closin)
> Forked execution prevents correct ServerSocket closing
> --
>
> Key: SUREFIRE-1587
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1587
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 2.22.1
> Environment: Linux, problem becomes visible on archlinux and also on
> Travis CI
>Reporter: Johannes Wienke
>Priority: Major
>
> The default mode of forked unit test execution (with JUnit) seems to
> interfere with socket operations. In our case, we see that with a surefire
> execution in forked mode, ServerSocket instances, despite returning from a
> close() call, are sometimes not correctly closed and a subsequent try to
> acquire a server socket on the same port then fails. This does not happen
> outside of surefire or when forkMode is set to none.
> Here is a simple test case to try this. First the maven project pom.xml:
> {code:title=pom.xml|borderStyle=solid}
>
> 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
> testing
> testit
> 1.0-SNAPSHOT
> testit
> A simple testit.
> http://www.example.com
>
> UTF-8
> 1.7
> 1.7
>
>
>
> junit
> junit
> 4.11
> test
>
>
>
>
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.22.1
>
>
>
>
> {code}
> And here a test file to be placed into the test source tree:
> {code:title=AppTest.java|borderStyle=solid}
> package testing;
> import org.junit.Test;
> import java.net.ServerSocket;
> public class AppTest {
> @Test
> public void testSocketStuff() throws Exception {
> while (true) {
> System.out.println("Iteration");
> final ServerSocket socket = new ServerSocket(55444);
> socket.close();
> }
> }
> }
> {code}
> Executing this with the default options (forking mode enabled) will pretty
> soon end up in the following exception after some iterations:
> {code}
> [ERROR] testSocketStuff(testing.AppTest) Time elapsed: 1.376 s <<< ERROR!
> java.net.BindException: Address already in use (Bind failed)
> at testing.AppTest.testSocketStuff(AppTest.java:17)
> {code}
> Executing the same test with -DforkMode=none does not result in this failure
> and the loop runs endlessly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SUREFIRE-1587) Forked execution prevents correct ServerSocket closin
[
https://issues.apache.org/jira/browse/SUREFIRE-1587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Johannes Wienke updated SUREFIRE-1587:
--
Summary: Forked execution prevents correct ServerSocket closin (was:
Forked executions prevents correct ServerSocket closing)
> Forked execution prevents correct ServerSocket closin
> -
>
> Key: SUREFIRE-1587
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1587
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 2.22.1
> Environment: Linux, problem becomes visible on archlinux and also on
> Travis CI
>Reporter: Johannes Wienke
>Priority: Major
>
> The default mode of forked unit test execution (with JUnit) seems to
> interfere with socket operations. In our case, we see that with a surefire
> execution in forked mode, ServerSocket instances, despite returning from a
> close() call, are sometimes not correctly closed and a subsequent try to
> acquire a server socket on the same port then fails. This does not happen
> outside of surefire or when forkMode is set to none.
> Here is a simple test case to try this. First the maven project pom.xml:
> {code:title=pom.xml|borderStyle=solid}
>
> 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
> testing
> testit
> 1.0-SNAPSHOT
> testit
> A simple testit.
> http://www.example.com
>
> UTF-8
> 1.7
> 1.7
>
>
>
> junit
> junit
> 4.11
> test
>
>
>
>
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.22.1
>
>
>
>
> {code}
> And here a test file to be placed into the test source tree:
> {code:title=AppTest.java|borderStyle=solid}
> package testing;
> import org.junit.Test;
> import java.net.ServerSocket;
> public class AppTest {
> @Test
> public void testSocketStuff() throws Exception {
> while (true) {
> System.out.println("Iteration");
> final ServerSocket socket = new ServerSocket(55444);
> socket.close();
> }
> }
> }
> {code}
> Executing this with the default options (forking mode enabled) will pretty
> soon end up in the following exception after some iterations:
> {code}
> [ERROR] testSocketStuff(testing.AppTest) Time elapsed: 1.376 s <<< ERROR!
> java.net.BindException: Address already in use (Bind failed)
> at testing.AppTest.testSocketStuff(AppTest.java:17)
> {code}
> Executing the same test with -DforkMode=none does not result in this failure
> and the loop runs endlessly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (SUREFIRE-1587) Forked executions prevents correct ServerSocket closing
Johannes Wienke created SUREFIRE-1587:
-
Summary: Forked executions prevents correct ServerSocket closing
Key: SUREFIRE-1587
URL: https://issues.apache.org/jira/browse/SUREFIRE-1587
Project: Maven Surefire
Issue Type: Bug
Affects Versions: 2.22.1
Environment: Linux, problem becomes visible on archlinux and also on
Travis CI
Reporter: Johannes Wienke
The default mode of forked unit test execution (with JUnit) seems to interfere
with socket operations. In our case, we see that with a surefire execution in
forked mode, ServerSocket instances, despite returning from a close() call, are
sometimes not correctly closed and a subsequent try to acquire a server socket
on the same port then fails. This does not happen outside of surefire or when
forkMode is set to none.
Here is a simple test case to try this. First the maven project pom.xml:
{code:title=pom.xml|borderStyle=solid}
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
testing
testit
1.0-SNAPSHOT
testit
A simple testit.
http://www.example.com
UTF-8
1.7
1.7
junit
junit
4.11
test
org.apache.maven.plugins
maven-surefire-plugin
2.22.1
{code}
And here a test file to be placed into the test source tree:
{code:title=AppTest.java|borderStyle=solid}
package testing;
import org.junit.Test;
import java.net.ServerSocket;
public class AppTest {
@Test
public void testSocketStuff() throws Exception {
while (true) {
System.out.println("Iteration");
final ServerSocket socket = new ServerSocket(55444);
socket.close();
}
}
}
{code}
Executing this with the default options (forking mode enabled) will pretty soon
end up in the following exception after some iterations:
{code}
[ERROR] testSocketStuff(testing.AppTest) Time elapsed: 1.376 s <<< ERROR!
java.net.BindException: Address already in use (Bind failed)
at testing.AppTest.testSocketStuff(AppTest.java:17)
{code}
Executing the same test with -DforkMode=none does not result in this failure
and the loop runs endlessly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MPMD-225) Create report even if no warnings have been found
[ https://issues.apache.org/jira/browse/MPMD-225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15409784#comment-15409784 ] Johannes Wienke commented on MPMD-225: -- This looks good. A switched default would make more sense to me. Otherwise, people might question whether checks have worked at all. > Create report even if no warnings have been found > -- > > Key: MPMD-225 > URL: https://issues.apache.org/jira/browse/MPMD-225 > Project: Maven PMD Plugin > Issue Type: Wish >Reporter: Johannes Wienke > > Right now, no report for the site plugin is generated if no violations have > been found. This is sometimes quite confusing as this state cannot be > distinguished from "the plugin didn't work at all". Checkstyle for example > just generates an empty report in these cases, which is what I would also > like for the pmd plugin. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MPMD-225) Create report even if no warnings have been found
Johannes Wienke created MPMD-225: Summary: Create report even if no warnings have been found Key: MPMD-225 URL: https://issues.apache.org/jira/browse/MPMD-225 Project: Maven PMD Plugin Issue Type: Wish Reporter: Johannes Wienke Right now, no report for the site plugin is generated if no violations have been found. This is sometimes quite confusing as this state cannot be distinguished from "the plugin didn't work at all". Checkstyle for example just generates an empty report in these cases, which is what I would also like for the pmd plugin. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MCHECKSTYLE-299) build type check goal ignored source options when using phases "test site"
Johannes Wienke created MCHECKSTYLE-299:
---
Summary: build type check goal ignored source options when using
phases "test site"
Key: MCHECKSTYLE-299
URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-299
Project: Maven Checkstyle Plugin
Issue Type: Bug
Components: checkstyle:check
Affects Versions: 2.15
Environment: Apache Maven 3.3.3
(7994120775791599e205a5524ec3e0dfe41d4a06; 2015-04-22T13:57:37+02:00)
Maven home: /homes/jwienke/local/trusty/x86_64/opt/apache-maven-3.3.3
Java version: 1.8.0_05, vendor: Oracle Corporation
Java home: /vol/ai/java/versions/x64/jdk1.8.0_05/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "3.18.1-tf1-ll", arch: "amd64", family: "unix"
Reporter: Johannes Wienke
I have a project where we enforce a zero-warnings policy. For this purpose we
have included a call to {{checkstyle:check}} in the build phase using the
following configuration:
{code:xml}
org.apache.maven.plugins
maven-checkstyle-plugin
2.15
${project.basedir}/codecheck/checkstyle.xml
config_loc=${project.basedir}/codecheck
true
true
warning
true
${project.basedir}/src
checkstyle-validate
validate
check
{code}
Additionally, checkstyle is set up as a reporting goal in the reporting section:
{code:xml}
org.apache.maven.plugins
maven-checkstyle-plugin
2.15
${project.basedir}/codecheck/checkstyle.xml
config_loc=${project.basedir}/codecheck
true
${project.basedir}/src
{code}
The project contains multiple source trees and some contain generated code.
Therefore it is necessary to restrict checkstyle to only one of these trees
where the manually maintained code lives. Otherwise, the build would fail due
to warnings being detected in generated code.
This shown configuration works well when calling maven all of the following
ways:
{noformat}
mvn compile
mvn test
mvn site
mvn test site
{noformat}
However, when changing the deprecated {{sourceDirectory}} elements to the list
syntax with {{sourceDirectories}}, the last call {{mvn test site}} starts to
fail and ignores the specified source directories. All previous other calls
still work as expected.
When looking at the effective configuration using {{mvn -X}} I could see, that
in the last call version with "test site", the {{sourceDirectories}} list of
the check goal is again the complete list of source trees instead of the
specified one.
Since we are also using some plugins to include the generated code etc., a
reference to the complete POM might be helpful for debugging:
https://code.cor-lab.org/projects/rsb/repository/rsb-java/revisions/master/entry/pom.xml
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MPMD-171) Rule properties are ignored when run under MPMD
[
https://issues.apache.org/jira/browse/MPMD-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14572625#comment-14572625
]
Johannes Wienke commented on MPMD-171:
--
There is one more strange thing that I noticed: If i do a mvn clean compile
site, then there are several runs of the PMD plugin (and also checkstyle,
configured the same way), which completely ignore any configuration. This
doesn't happen if I do mvn site.
> Rule properties are ignored when run under MPMD
> ---
>
> Key: MPMD-171
> URL: https://issues.apache.org/jira/browse/MPMD-171
> Project: Maven PMD Plugin
> Issue Type: Bug
> Components: PMD
>Affects Versions: 3.0.1
> Environment: Linux
>Reporter: Johannes Wienke
>Assignee: Michael Osipov
> Fix For: 3.3, 3.4
>
>
> For our project I have defined a custom ruleset for PMD in an XML file [1].
> This ruleset defines properties for some of the standard PMD rules using this
> syntax:
> {noformat}
>
>
>
>
>
> {noformat}
> When I execute PMD using a parallel ant file we maintain, these custom
> properties are respected correctly. However, when executing PMD through
> maven, the properties are completely ignored.
> The pom.xml we are using is available at [2].
> [1]
> https://code.cor-lab.org/projects/rsb/repository/rsb-java/revisions/7e71d4d3e6d57c8529111a7f7143edeb48ddec59/entry/codecheck/pmd-rules.xml
> [2]
> https://code.cor-lab.org/projects/rsb/repository/rsb-java/revisions/ff17c0dd008697f70dad27bd0319f4475ab87712/entry/pom.xml
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MPMD-171) Rule properties are ignored when run under MPMD
[
https://issues.apache.org/jira/browse/MPMD-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14572479#comment-14572479
]
Johannes Wienke commented on MPMD-171:
--
Yes that definitely helps. Is this documented somewhere? Otherwise, having this
at least as an example in the documentation would be really helpful.
> Rule properties are ignored when run under MPMD
> ---
>
> Key: MPMD-171
> URL: https://issues.apache.org/jira/browse/MPMD-171
> Project: Maven PMD Plugin
> Issue Type: Bug
> Components: PMD
>Affects Versions: 3.0.1
> Environment: Linux
>Reporter: Johannes Wienke
>Assignee: Michael Osipov
> Fix For: 3.3, 3.4
>
>
> For our project I have defined a custom ruleset for PMD in an XML file [1].
> This ruleset defines properties for some of the standard PMD rules using this
> syntax:
> {noformat}
>
>
>
>
>
> {noformat}
> When I execute PMD using a parallel ant file we maintain, these custom
> properties are respected correctly. However, when executing PMD through
> maven, the properties are completely ignored.
> The pom.xml we are using is available at [2].
> [1]
> https://code.cor-lab.org/projects/rsb/repository/rsb-java/revisions/7e71d4d3e6d57c8529111a7f7143edeb48ddec59/entry/codecheck/pmd-rules.xml
> [2]
> https://code.cor-lab.org/projects/rsb/repository/rsb-java/revisions/ff17c0dd008697f70dad27bd0319f4475ab87712/entry/pom.xml
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MPMD-171) Rule properties are ignored when run under MPMD
[
https://issues.apache.org/jira/browse/MPMD-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14572436#comment-14572436
]
Johannes Wienke commented on MPMD-171:
--
Sorry, I forgot to push the actual commit :/ This is what I tried:
https://code.cor-lab.org/projects/rsb/repository/rsb-java/diff?utf8=%E2%9C%93&rev=86f56bd140bf5de12dcb0aab83d2065e10dd05fc&rev_to=02ea0f321e745968b10d1a7dd422e9619603bf71
> Rule properties are ignored when run under MPMD
> ---
>
> Key: MPMD-171
> URL: https://issues.apache.org/jira/browse/MPMD-171
> Project: Maven PMD Plugin
> Issue Type: Bug
> Components: PMD
>Affects Versions: 3.0.1
> Environment: Linux
>Reporter: Johannes Wienke
>Assignee: Michael Osipov
> Fix For: 3.3, 3.4
>
>
> For our project I have defined a custom ruleset for PMD in an XML file [1].
> This ruleset defines properties for some of the standard PMD rules using this
> syntax:
> {noformat}
>
>
>
>
>
> {noformat}
> When I execute PMD using a parallel ant file we maintain, these custom
> properties are respected correctly. However, when executing PMD through
> maven, the properties are completely ignored.
> The pom.xml we are using is available at [2].
> [1]
> https://code.cor-lab.org/projects/rsb/repository/rsb-java/revisions/7e71d4d3e6d57c8529111a7f7143edeb48ddec59/entry/codecheck/pmd-rules.xml
> [2]
> https://code.cor-lab.org/projects/rsb/repository/rsb-java/revisions/ff17c0dd008697f70dad27bd0319f4475ab87712/entry/pom.xml
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MPMD-171) Rule properties are ignored when run under MPMD
[
https://issues.apache.org/jira/browse/MPMD-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14571594#comment-14571594
]
Johannes Wienke commented on MPMD-171:
--
Strange, when I do "mvn clean compile" I get different warnings compared to
when I do "mvn clean compile site". But either the warnings are less then
expected or too many. They never match what is correctly reported in the site
report.
> Rule properties are ignored when run under MPMD
> ---
>
> Key: MPMD-171
> URL: https://issues.apache.org/jira/browse/MPMD-171
> Project: Maven PMD Plugin
> Issue Type: Bug
> Components: PMD
>Affects Versions: 3.0.1
> Environment: Linux
>Reporter: Johannes Wienke
>Assignee: Michael Osipov
> Fix For: 3.3, 3.4
>
>
> For our project I have defined a custom ruleset for PMD in an XML file [1].
> This ruleset defines properties for some of the standard PMD rules using this
> syntax:
> {noformat}
>
>
>
>
>
> {noformat}
> When I execute PMD using a parallel ant file we maintain, these custom
> properties are respected correctly. However, when executing PMD through
> maven, the properties are completely ignored.
> The pom.xml we are using is available at [2].
> [1]
> https://code.cor-lab.org/projects/rsb/repository/rsb-java/revisions/7e71d4d3e6d57c8529111a7f7143edeb48ddec59/entry/codecheck/pmd-rules.xml
> [2]
> https://code.cor-lab.org/projects/rsb/repository/rsb-java/revisions/ff17c0dd008697f70dad27bd0319f4475ab87712/entry/pom.xml
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MPMD-171) Rule properties are ignored when run under MPMD
[
https://issues.apache.org/jira/browse/MPMD-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14571584#comment-14571584
]
Johannes Wienke commented on MPMD-171:
--
Ah sorry, I tried this on a different project. But since you already know the
RSB project, I have reproduced the settings in a branch called
"wip-checks-during-build". You can actually see, that nothing of the provided
configuration is used by the plugin, because event the excluded directories are
scanned.
> Rule properties are ignored when run under MPMD
> ---
>
> Key: MPMD-171
> URL: https://issues.apache.org/jira/browse/MPMD-171
> Project: Maven PMD Plugin
> Issue Type: Bug
> Components: PMD
>Affects Versions: 3.0.1
> Environment: Linux
>Reporter: Johannes Wienke
>Assignee: Michael Osipov
> Fix For: 3.3, 3.4
>
>
> For our project I have defined a custom ruleset for PMD in an XML file [1].
> This ruleset defines properties for some of the standard PMD rules using this
> syntax:
> {noformat}
>
>
>
>
>
> {noformat}
> When I execute PMD using a parallel ant file we maintain, these custom
> properties are respected correctly. However, when executing PMD through
> maven, the properties are completely ignored.
> The pom.xml we are using is available at [2].
> [1]
> https://code.cor-lab.org/projects/rsb/repository/rsb-java/revisions/7e71d4d3e6d57c8529111a7f7143edeb48ddec59/entry/codecheck/pmd-rules.xml
> [2]
> https://code.cor-lab.org/projects/rsb/repository/rsb-java/revisions/ff17c0dd008697f70dad27bd0319f4475ab87712/entry/pom.xml
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MPMD-171) Rule properties are ignored when run under MPMD
[
https://issues.apache.org/jira/browse/MPMD-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14571004#comment-14571004
]
Johannes Wienke commented on MPMD-171:
--
I am still experiencing this bug with the 3.4 release of MPMD. That release
should contain the fix?
> Rule properties are ignored when run under MPMD
> ---
>
> Key: MPMD-171
> URL: https://issues.apache.org/jira/browse/MPMD-171
> Project: Maven PMD Plugin
> Issue Type: Bug
> Components: PMD
>Affects Versions: 3.0.1
> Environment: Linux
>Reporter: Johannes Wienke
>Assignee: Michael Osipov
> Fix For: 3.3, 3.4
>
>
> For our project I have defined a custom ruleset for PMD in an XML file [1].
> This ruleset defines properties for some of the standard PMD rules using this
> syntax:
> {noformat}
>
>
>
>
>
> {noformat}
> When I execute PMD using a parallel ant file we maintain, these custom
> properties are respected correctly. However, when executing PMD through
> maven, the properties are completely ignored.
> The pom.xml we are using is available at [2].
> [1]
> https://code.cor-lab.org/projects/rsb/repository/rsb-java/revisions/7e71d4d3e6d57c8529111a7f7143edeb48ddec59/entry/codecheck/pmd-rules.xml
> [2]
> https://code.cor-lab.org/projects/rsb/repository/rsb-java/revisions/ff17c0dd008697f70dad27bd0319f4475ab87712/entry/pom.xml
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] (MPMD-171) Rule properties are ignored when run under MPMD
Johannes Wienke created MPMD-171:
Summary: Rule properties are ignored when run under MPMD
Key: MPMD-171
URL: https://jira.codehaus.org/browse/MPMD-171
Project: Maven PMD Plugin
Issue Type: Bug
Components: PMD
Affects Versions: 3.0.1
Environment: Linux
Reporter: Johannes Wienke
For our project I have defined a custom ruleset for PMD in an XML file [1].
This ruleset defines properties for some of the standard PMD rules using this
syntax:
{noformat}
{noformat}
When I execute PMD using a parallel ant file we maintain, these custom
properties are respected correctly. However, when executing PMD through maven,
the properties are completely ignored.
The pom.xml we are using is available at [2].
[1]
https://code.cor-lab.org/projects/rsb/repository/rsb-java/revisions/7e71d4d3e6d57c8529111a7f7143edeb48ddec59/entry/codecheck/pmd-rules.xml
[2]
https://code.cor-lab.org/projects/rsb/repository/rsb-java/revisions/ff17c0dd008697f70dad27bd0319f4475ab87712/entry/pom.xml
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
