[jira] [Commented] (MCHECKSTYLE-314) checkstyle:check should invoke the execution of this plugin's goal "checkstyle" prior to executing itself
[
https://issues.apache.org/jira/browse/MCHECKSTYLE-314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16036129#comment-16036129
]
Stig Rohde Døssing commented on MCHECKSTYLE-314:
[~michael-o] This fix seems broken to me. checkstyle:check runs Checkstyle on
its own, so with this patch Checkstyle ends up running twice when
checkstyle:check is invoked. For example, we have the following configuration
for Apache Storm (plugin version is bumped from 2.17, but that's the only
change):
{code}
org.apache.maven.plugins
maven-checkstyle-plugin
3.0.0-SNAPSHOT
com.puppycrawl.tools
checkstyle
7.7
validate
validate
storm-buildtools/storm_checkstyle.xml
UTF-8
true
false
target/checkstyle-violation.xml
warning
check
{code}
With version 2.17 we correctly get a checkstyle-violation.xml in our target
folder, and warnings in the console when there are violations.
With the code currently on trunk we get an additional
{code}
[INFO] There are 34506 errors reported by Checkstyle 7.7 with sun_checks.xml
ruleset.
[WARNING] Unable to locate Source XRef to link to - DISABLED
{code}
which is clearly misleading, since we are not using the sun_checks.xml ruleset.
We also end up with both the expected checkstyle-violation.xml and an
additional checkstyle-results.xml in the target folder. The
checkstyle-results.xml is generated by the checkstyle:checkstyle execution, and
so contains violations for the Sun ruleset. It seems likely to me that someone
will accidentally open the wrong file at some point, and start correcting the
wrong violations.
I think either this change should be reverted, or the
CheckstyleViolationCheckMojo should be rewritten so it doesn't run Checkstyle
itself, but delegates that task to the checkstyle:checkstyle goal. I'm not
familiar enough with Mojo development to know if it's possible to do the second
option without breaking backward compatibility. The PMD plugin is able to make
{{check}} run {{pmd}} because they have a cleaner separation between the
{{pmd}} and {{check}} goals, e.g. the {{check}} goal doesn't have any
parameters to configure PMD execution. This makes it easy for them to just
invoke the {{pmd}} goal, because they don't have to deal with trying to pass
configuration from the {{check}} goal to {{pmd}}.
> checkstyle:check should invoke the execution of this plugin's goal
> "checkstyle" prior to executing itself
> -
>
> Key: MCHECKSTYLE-314
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-314
> Project: Maven Checkstyle Plugin
> Issue Type: Improvement
>Affects Versions: 2.17
>Reporter: Roman Ivanov
>Assignee: Michael Osipov
> Fix For: 3.0.0
>
>
> I run into problem with using checkstyles goal "checkstyle:check" in
> sevntu.checkstyle project
> (https://github.com/sevntu-checkstyle/sevntu.checkstyle/blob/master/sevntu-checks/pom.xml#L75)
> as it always use default Sun config when I run "checkstyle:check", It took
> me a while to figure out why that does not work.
> I had a habit and convenience to run in such a ways pmd and findbug, just
> "mvn pmd:check", "mvn findbug:check" it is human friendly.
> PMD and Findbugs plugins already do this:
> http://gleclaire.github.io/findbugs-maven-plugin/check-mojo.html
> https://maven.apache.org/plugins/maven-pmd-plugin/check-mojo.html
> search for "Invokes the execution of this plugin's goal"
> vs
> http://maven.apache.org/plugins/maven-checkstyle-plugin/check-mojo.html
> Problem was also raised at :
> http://stackoverflow.com/questions/11106767/maven-checkstylecheck-not-working
> Please add support of this, most users are not professionals in Maven. I use
> Maven for many years and it took me too much time to find a reason why it
> does not work.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MCHECKSTYLE-337) checkstyle:check only supports xml output format, but the docs say it supports plain as well
[ https://issues.apache.org/jira/browse/MCHECKSTYLE-337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stig Rohde Døssing updated MCHECKSTYLE-337: --- Attachment: MCHECKSTYLE-337.patch Whoops, first version was based off 2.17, not trunk, sorry. I added an integration test for this issue. Just in case you wonder why there's a checkstyle-report.xml alongside the checkstyle-report.txt in the target directory of the integration test, it's because https://issues.apache.org/jira/browse/MCHECKSTYLE-314 made checkstyle:check run checkstyle:checkstyle first, so Checkstyle is actually being run twice. The xml file is from the checkstyle:checkstyle execution. > checkstyle:check only supports xml output format, but the docs say it > supports plain as well > > > Key: MCHECKSTYLE-337 > URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-337 > Project: Maven Checkstyle Plugin > Issue Type: Bug > Components: checkstyle:check >Affects Versions: 2.17 >Reporter: Stig Rohde Døssing >Priority: Minor > Attachments: MCHECKSTYLE-337.patch, MCHECKSTYLE-337.patch > > > The documentation for the check goal at > https://maven.apache.org/plugins/maven-checkstyle-plugin/check-mojo.html#outputFileFormat > mentions "plain" as a valid option for file output. This is not true, the > mojo only supports XML. > I'd prefer added support for plain output, but the docs should be fixed if > that is not possible. > Taking a look at the code, it looks like the only reason plain isn't > supported is because the check mojo needs to parse the output file to figure > out if there were style violations. An option would be counting errors with > the AuditListener instead, but this would break support for skipExec. An > alternative would be to output an extra XML result file if the output format > isn't XML. > I'd be happy to implement either solution. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Issue Comment Deleted] (MDEP-560) maven-dependency-plugin ignores method references passed as parameter
[
https://issues.apache.org/jira/browse/MDEP-560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Gettys updated MDEP-560:
---
Comment: was deleted
(was: I can't comment for the OP, but I'm using maven 3.5.0)
> maven-dependency-plugin ignores method references passed as parameter
> -
>
> Key: MDEP-560
> URL: https://issues.apache.org/jira/browse/MDEP-560
> Project: Maven Dependency Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: Vladimir Dergachev
>Priority: Minor
>
> I created example for commons-lang library
> https://gist.github.com/vdergachev/3dd0908ec0301b1e0357005e669cc726
> My applications contains few modules, in parent pom.xml i have regular entry
> {code}
>
> 1.8
> ...
>
>
>
>
>
> commons-lang
> commons-lang
> 2.6
>
> ...
>
>
> {code}
> in module's pom ONLY spring deps, so i don't have commons-lang library in
> module dependencies, but test runs fine. As you can see I passed reference
> StringUtils::isEmpty as a parameter to method. When part 2 uncommented and
> method StringUtils.isEmpty called directly in code i will have correct error
> message from maven-dependency-plugin
> {code}
> [INFO] — maven-dependency-plugin:3.0.0:analyze-only (analyze-dependencies)
> [WARNING] Used undeclared dependencies found:
> [WARNING] commons-lang:commons-lang:jar:2.6:compile
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MDEP-560) maven-dependency-plugin ignores method references passed as parameter
[
https://issues.apache.org/jira/browse/MDEP-560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16036100#comment-16036100
]
Robert Gettys commented on MDEP-560:
I can't comment for the OP, but I'm using maven 3.5.0
> maven-dependency-plugin ignores method references passed as parameter
> -
>
> Key: MDEP-560
> URL: https://issues.apache.org/jira/browse/MDEP-560
> Project: Maven Dependency Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: Vladimir Dergachev
>Priority: Minor
>
> I created example for commons-lang library
> https://gist.github.com/vdergachev/3dd0908ec0301b1e0357005e669cc726
> My applications contains few modules, in parent pom.xml i have regular entry
> {code}
>
> 1.8
> ...
>
>
>
>
>
> commons-lang
> commons-lang
> 2.6
>
> ...
>
>
> {code}
> in module's pom ONLY spring deps, so i don't have commons-lang library in
> module dependencies, but test runs fine. As you can see I passed reference
> StringUtils::isEmpty as a parameter to method. When part 2 uncommented and
> method StringUtils.isEmpty called directly in code i will have correct error
> message from maven-dependency-plugin
> {code}
> [INFO] — maven-dependency-plugin:3.0.0:analyze-only (analyze-dependencies)
> [WARNING] Used undeclared dependencies found:
> [WARNING] commons-lang:commons-lang:jar:2.6:compile
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MDEP-569) copy fails on artifacts previously downloaded via get from repo specified via CLI
[
https://issues.apache.org/jira/browse/MDEP-569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16036086#comment-16036086
]
Guillaume Boué commented on MDEP-569:
-
Yes, adding a {{remoteRepositories}} parameter to the goal would work, but note
that every time you'll need to use this dependency in a project, the Confluent
repository will have to be active. So it is probably preferable to declare this
repository in your settings once and for all.
> copy fails on artifacts previously downloaded via get from repo specified via
> CLI
> -
>
> Key: MDEP-569
> URL: https://issues.apache.org/jira/browse/MDEP-569
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: copy, get
>Affects Versions: 3.0.1
> Environment: Apache Maven 3.5.0
> (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T19:39:06Z)
> Maven home: /usr/share/maven
> Java version: 1.8.0_121, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-1.8-openjdk/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.8.0-52-generic", arch: "amd64", family: "unix"
>Reporter: Tom Wieczorek
> Attachments: dependency-copy-problem-output.txt
>
>
> {{dependency:copy}} fails to copy artifacts that were previously downloaded
> via {{dependency:get}} from a remote repository that has been specified on
> the command line. The error message is:
> bq. The POM for artifact is missing, no dependency information available
> and later on
> bq. Failed to execute goal dependency:copy (default-cli) on project
> standalone-pom: Unable to find/resolve artifact. Failure to find artifact in
> https://repo.maven.apache.org/maven2 was cached in the local repository,
> resolution will not be reattempted until the update interval of central has
> elapsed or updates are forced
> But: {{dependency:get}} actually succeeded and the artifact and its POM are
> in the local repo.
> {code:none|title=Reproducing shell snippet}
> mvn -version
> mvn org.apache.maven.plugins:maven-dependency-plugin:3.0.1:get \
> org.apache.maven.plugins:maven-dependency-plugin:3.0.1:copy \
> -DremoteRepositories=http://packages.confluent.io/maven/ \
> -Dartifact=io.confluent:kafka-schema-registry:3.1.1
> ls -la ~/.m2/repository/io/confluent/kafka-schema-registry/3.1.1
> {code}
> I've attached the output of the above test snippets.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MDEP-560) maven-dependency-plugin ignores method references passed as parameter
[
https://issues.apache.org/jira/browse/MDEP-560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16036074#comment-16036074
]
Guillaume Boué commented on MDEP-560:
-
This looks already fixed in version 3.0.1. Can you try with this version? In
this version, the code
{code:java}
foo(Arrays.asList("one", null, "three"), StringUtils::isEmpty);
{code}
and a dependency on a project that has {{commons-lang}} 2.6 as transitive
dependency, I get the warning about the used undeclared dependency.
> maven-dependency-plugin ignores method references passed as parameter
> -
>
> Key: MDEP-560
> URL: https://issues.apache.org/jira/browse/MDEP-560
> Project: Maven Dependency Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: Vladimir Dergachev
>Priority: Minor
>
> I created example for commons-lang library
> https://gist.github.com/vdergachev/3dd0908ec0301b1e0357005e669cc726
> My applications contains few modules, in parent pom.xml i have regular entry
> {code}
>
> 1.8
> ...
>
>
>
>
>
> commons-lang
> commons-lang
> 2.6
>
> ...
>
>
> {code}
> in module's pom ONLY spring deps, so i don't have commons-lang library in
> module dependencies, but test runs fine. As you can see I passed reference
> StringUtils::isEmpty as a parameter to method. When part 2 uncommented and
> method StringUtils.isEmpty called directly in code i will have correct error
> message from maven-dependency-plugin
> {code}
> [INFO] — maven-dependency-plugin:3.0.0:analyze-only (analyze-dependencies)
> [WARNING] Used undeclared dependencies found:
> [WARNING] commons-lang:commons-lang:jar:2.6:compile
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MCHECKSTYLE-337) checkstyle:check only supports xml output format, but the docs say it supports plain as well
[
https://issues.apache.org/jira/browse/MCHECKSTYLE-337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16036068#comment-16036068
]
Guillaume Boué commented on MCHECKSTYLE-337:
Thanks! The patch must be a few months old because it doesn't apply anymore
with the latest codebase. Could you bring it up to date?
I've looked at the diff and it looks good. If you could also add an integration
test with {{plain}} output format, that, for example, verifies the checkstyle
plain result was generated, it would be great (they are under {{src/it}}, where
there are example, and are run when building the project with the {{run-its}}
profile).
I like the idea between {{CompositeAuditListener}}, that can be useful to
factor out some more code in the plugin.
> checkstyle:check only supports xml output format, but the docs say it
> supports plain as well
>
>
> Key: MCHECKSTYLE-337
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-337
> Project: Maven Checkstyle Plugin
> Issue Type: Bug
> Components: checkstyle:check
>Affects Versions: 2.17
>Reporter: Stig Rohde Døssing
>Priority: Minor
> Attachments: MCHECKSTYLE-337.patch
>
>
> The documentation for the check goal at
> https://maven.apache.org/plugins/maven-checkstyle-plugin/check-mojo.html#outputFileFormat
> mentions "plain" as a valid option for file output. This is not true, the
> mojo only supports XML.
> I'd prefer added support for plain output, but the docs should be fixed if
> that is not possible.
> Taking a look at the code, it looks like the only reason plain isn't
> supported is because the check mojo needs to parse the output file to figure
> out if there were style violations. An option would be counting errors with
> the AuditListener instead, but this would break support for skipExec. An
> alternative would be to output an extra XML result file if the output format
> isn't XML.
> I'd be happy to implement either solution.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1376) "The forked VM terminated without properly saying goodbye" when running Surefire in a very deep project structure on Windows
[
https://issues.apache.org/jira/browse/SUREFIRE-1376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16035954#comment-16035954
]
Hudson commented on SUREFIRE-1376:
--
SUCCESS: Integrated in Jenkins build maven-surefire #1712 (See
[https://builds.apache.org/job/maven-surefire/1712/])
[SUREFIRE-1376] "The forked VM terminated without properly saying (tibor17:
[http://git-wip-us.apache.org/repos/asf/?p=maven-surefire.git&a=commit&h=59c065f5d4a5a9c181ef9ce788b31305886e8592])
* (edit)
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/booterclient/ForkConfiguration.java
* (edit)
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/SurefireHelper.java
* (edit)
maven-surefire-common/src/test/java/org/apache/maven/plugin/surefire/SurefireHelperTest.java
> "The forked VM terminated without properly saying goodbye" when running
> Surefire in a very deep project structure on Windows
>
>
> Key: SUREFIRE-1376
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1376
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 2.20
> Environment: Windows
>Reporter: Guillaume Boué
>Assignee: Tibor Digana
> Fix For: 2.20.1
>
> Attachments: SUREFIRE-1376-prefix.patch
>
>
> When Surefire is ran on a project under a very long path (exceeding Windows'
> {{MAX_PATH}}), the invocation fails with
> {noformat}
> org.apache.maven.surefire.booter.SurefireBooterForkException: The forked VM
> terminated without properly saying goodbye. VM crash or System.exit called?
> {noformat}
> In the generated dumpstream, there is
> {noformat}
> # Created on 2017-05-28T10:17:09.474
> Error: Unable to access jarfile
> C:\Users\Guillaume\Desktop\surefire-longpath-test-with-windows\surefire-longpath-test-with-windows\surefire-longpath-test-with-windows\surefire-longpath-test-with-windows\surefire-longpath-test-with-windows\surefire-longpath-test-with-windows\target\surefire\surefirebooter2512478076549179739.jar
> {noformat}
> The problem is that the path to the JAR file exceeds the maximum path length
> of 260 characters, and so it cannot be accessed.
> Prepending the path to the JAR file with {{\\?\}}, [as documented
> on
> MSDN|https://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx#maxpath],
> makes the test run again correctly. I've attached a possible patch with this
> approach (SUREFIRE-1376-prefix.patch, that also handles UNC pathnames), but
> perhaps there is a better way to tackle this problem.
> In order to reproduce this, it is possible to create a project under lots of
> different subdirectories, something like:
> {noformat}
> └───surefire-longpath-test-with-windows
> └───surefire-longpath-test-with-windows
> └───surefire-longpath-test-with-windows
> └───surefire-longpath-test-with-windows
> └───surefire-longpath-test-with-windows
> │ pom.xml
> │
> └───src
> └───test
> └───java
> └───Test.java
> {noformat}
> As a side-note, this issue is behind the current Jenkins failures on
> [maven-plugins-ITs-m3.1.x-with-maven-plugin-jdk-1.8_windows|https://builds.apache.org/job/maven-plugins-ITs-m3.1.x-with-maven-plugin-jdk-1.8_windows/3702/]
> when running the ITs on the Assembly Plugin.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (SUREFIRE-1380) AbstractCommandStream should flush data if another Thread marks the stream closed, empty shared buffer.
[
https://issues.apache.org/jira/browse/SUREFIRE-1380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-1380:
---
Description:
Another flush is necessary because the method {{AbstractCommandStream.read()}}
is called
in a loop and the flush should be called after last byte. This normally happens
if the loop is not stopped. If another thread marks the
{{AbstractCommandStream}}'s Thread to be closed asynchronously, then the bytes
can be lost in the Thread calling {{read()}} method.
Therefore flushing if stream has been marked for closing it in the intermediate
time between these two threads.
If {{InputStream}} is closed after marking it then no flush helps of course.
This was on the side of Maven process which sends commands to forked JVM. If
the fork does not receive complete data, even if flushed by Maven process,
nothing special happens. The fork remains in the state of reading till command
is read complete or stops after JVM timing out or JVM is killed. If the fork
receives complete command, even better.
was:
Another flush is necessary because the method {{AbstractCommandStream.read()}}
is called
in a loop and the flush should be called after last byte. This normally happens
if the loop is not stopped. If another thread marks the
{{AbstractCommandStream}}'s Thread to be closed asynchronously, then the bytes
can be lost in the Thread calling {{read()}} method.
Therefore flushing if stream has been marked for closing it in the intermediate
time between these two threads.
If {{InputStream}} is closed after marking it then no flush helps of course.
This was on the side of Maven process which sends commands to forked JVM. If
the fork does not receive complete data, even if flushed by Maven process,
nothing special happens. The fork remains in the state of reading complete
command or stops after timing out. If the fork receives complete command, even
better.
> AbstractCommandStream should flush data if another Thread marks the stream
> closed, empty shared buffer.
> ---
>
> Key: SUREFIRE-1380
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1380
> Project: Maven Surefire
> Issue Type: Task
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Reporter: Tibor Digana
>Assignee: Tibor Digana
> Fix For: 2.20.1
>
>
> Another flush is necessary because the method
> {{AbstractCommandStream.read()}} is called
> in a loop and the flush should be called after last byte. This normally
> happens if the loop is not stopped. If another thread marks the
> {{AbstractCommandStream}}'s Thread to be closed asynchronously, then the
> bytes can be lost in the Thread calling {{read()}} method.
> Therefore flushing if stream has been marked for closing it in the
> intermediate time between these two threads.
> If {{InputStream}} is closed after marking it then no flush helps of course.
> This was on the side of Maven process which sends commands to forked JVM. If
> the fork does not receive complete data, even if flushed by Maven process,
> nothing special happens. The fork remains in the state of reading till
> command is read complete or stops after JVM timing out or JVM is killed. If
> the fork receives complete command, even better.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (SUREFIRE-1380) AbstractCommandStream should flush data if another Thread marks the stream closed, empty shared buffer.
[
https://issues.apache.org/jira/browse/SUREFIRE-1380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-1380:
---
Description:
Another flush is necessary because the method {{AbstractCommandStream.read()}}
is called
in a loop and the flush should be called after last byte. This normally happens
if the loop is not stopped. If another thread marks the
{{AbstractCommandStream}}'s Thread to be closed asynchronously, then the bytes
can be lost in the Thread calling {{read()}} method.
Therefore flushing if stream has been marked for closing it in the intermediate
time between these two threads.
If {{InputStream}} is closed after marking it then no flush helps of course.
This was on the side of Maven process which sends commands to forked JVM. If
the fork does not receive complete data, even if flushed by Maven process,
nothing special happens. The fork remains in the state of reading complete
command or stops after timing out. If the fork receives complete command, even
better.
was:
Another flush is necessary because the method {{AbstractCommandStream.read()}}
is called
in a loop and the flush should be called after last byte. This normally happens
if the loop is not stopped. If another thread marks the
{{AbstractCommandStream}}'s Thread to be closed asynchronously, then the bytes
can be lost in the Thread calling {{read()}} method.
Therefore flushing if stream has been marked for closing it in the intermediate
time between these two threads.
If {{InputStream}} is closed after marking it then no flush helps of course.
This was on the side of Maven process which sends commands to forked JVM. If
the fork does not receive complete data, even if flushed by Maven process,
nothing special happens. The fork remains in the state of reading complete
command or stops after timing out.
> AbstractCommandStream should flush data if another Thread marks the stream
> closed, empty shared buffer.
> ---
>
> Key: SUREFIRE-1380
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1380
> Project: Maven Surefire
> Issue Type: Task
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Reporter: Tibor Digana
>Assignee: Tibor Digana
> Fix For: 2.20.1
>
>
> Another flush is necessary because the method
> {{AbstractCommandStream.read()}} is called
> in a loop and the flush should be called after last byte. This normally
> happens if the loop is not stopped. If another thread marks the
> {{AbstractCommandStream}}'s Thread to be closed asynchronously, then the
> bytes can be lost in the Thread calling {{read()}} method.
> Therefore flushing if stream has been marked for closing it in the
> intermediate time between these two threads.
> If {{InputStream}} is closed after marking it then no flush helps of course.
> This was on the side of Maven process which sends commands to forked JVM. If
> the fork does not receive complete data, even if flushed by Maven process,
> nothing special happens. The fork remains in the state of reading complete
> command or stops after timing out. If the fork receives complete command,
> even better.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (SUREFIRE-1380) AbstractCommandStream should flush data if another Thread marks the stream closed, empty shared buffer.
[
https://issues.apache.org/jira/browse/SUREFIRE-1380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-1380:
---
Description:
Another flush is necessary because the method {{AbstractCommandStream.read()}}
is called
in a loop and the flush should be called after last byte. This normally happens
if the loop is not stopped. If another thread marks the
{{AbstractCommandStream}}'s Thread to be closed asynchronously, then the bytes
can be lost in the Thread calling {{read()}} method.
Therefore flushing if stream has been marked for closing it in the intermediate
time between these two threads.
If {{InputStream}} is closed after marking it then no flush helps of course.
This was on the side of Maven process which sends commands to forked JVM. If
the fork does not receive complete data, even if flushed, nothing special
happens. The fork remains in the state of reading complete command or stops
after timing out.
was:
Another flush is necessary because the method {{AbstractCommandStream.read()}}
is called
in a loop and the flush should be called after last byte. This normally happens
if the loop is not stopped. If another thread marks the
{{AbstractCommandStream}}'s Thread to be closed asynchronously, then the bytes
can be lost in the Thread calling {{read()}} method.
Therefore flushing if stream has been marked for closing it in the intermediate
time between these two threads.
This was on the side of Maven process which sends commands to forked JVM. If
the fork does not receive complete data, even if flushed, nothing special
happens. The fork remains in the state of reading complete command or stops
after timing out.
If {{InputStream}} is closed after marking it then no flush helps of course.
> AbstractCommandStream should flush data if another Thread marks the stream
> closed, empty shared buffer.
> ---
>
> Key: SUREFIRE-1380
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1380
> Project: Maven Surefire
> Issue Type: Task
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Reporter: Tibor Digana
>Assignee: Tibor Digana
> Fix For: 2.20.1
>
>
> Another flush is necessary because the method
> {{AbstractCommandStream.read()}} is called
> in a loop and the flush should be called after last byte. This normally
> happens if the loop is not stopped. If another thread marks the
> {{AbstractCommandStream}}'s Thread to be closed asynchronously, then the
> bytes can be lost in the Thread calling {{read()}} method.
> Therefore flushing if stream has been marked for closing it in the
> intermediate time between these two threads.
> If {{InputStream}} is closed after marking it then no flush helps of course.
> This was on the side of Maven process which sends commands to forked JVM. If
> the fork does not receive complete data, even if flushed, nothing special
> happens. The fork remains in the state of reading complete command or stops
> after timing out.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (SUREFIRE-1380) AbstractCommandStream should flush data if another Thread marks the stream closed, empty shared buffer.
[
https://issues.apache.org/jira/browse/SUREFIRE-1380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-1380:
---
Description:
Another flush is necessary because the method {{AbstractCommandStream.read()}}
is called
in a loop and the flush should be called after last byte. This normally happens
if the loop is not stopped. If another thread marks the
{{AbstractCommandStream}}'s Thread to be closed asynchronously, then the bytes
can be lost in the Thread calling {{read()}} method.
Therefore flushing if stream has been marked for closing it in the intermediate
time between these two threads.
If {{InputStream}} is closed after marking it then no flush helps of course.
This was on the side of Maven process which sends commands to forked JVM. If
the fork does not receive complete data, even if flushed by Maven process,
nothing special happens. The fork remains in the state of reading complete
command or stops after timing out.
was:
Another flush is necessary because the method {{AbstractCommandStream.read()}}
is called
in a loop and the flush should be called after last byte. This normally happens
if the loop is not stopped. If another thread marks the
{{AbstractCommandStream}}'s Thread to be closed asynchronously, then the bytes
can be lost in the Thread calling {{read()}} method.
Therefore flushing if stream has been marked for closing it in the intermediate
time between these two threads.
If {{InputStream}} is closed after marking it then no flush helps of course.
This was on the side of Maven process which sends commands to forked JVM. If
the fork does not receive complete data, even if flushed, nothing special
happens. The fork remains in the state of reading complete command or stops
after timing out.
> AbstractCommandStream should flush data if another Thread marks the stream
> closed, empty shared buffer.
> ---
>
> Key: SUREFIRE-1380
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1380
> Project: Maven Surefire
> Issue Type: Task
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Reporter: Tibor Digana
>Assignee: Tibor Digana
> Fix For: 2.20.1
>
>
> Another flush is necessary because the method
> {{AbstractCommandStream.read()}} is called
> in a loop and the flush should be called after last byte. This normally
> happens if the loop is not stopped. If another thread marks the
> {{AbstractCommandStream}}'s Thread to be closed asynchronously, then the
> bytes can be lost in the Thread calling {{read()}} method.
> Therefore flushing if stream has been marked for closing it in the
> intermediate time between these two threads.
> If {{InputStream}} is closed after marking it then no flush helps of course.
> This was on the side of Maven process which sends commands to forked JVM. If
> the fork does not receive complete data, even if flushed by Maven process,
> nothing special happens. The fork remains in the state of reading complete
> command or stops after timing out.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (SUREFIRE-1380) AbstractCommandStream should flush data if another Thread marks the stream closed, empty shared buffer.
[
https://issues.apache.org/jira/browse/SUREFIRE-1380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-1380:
---
Description:
Another flush is necessary because the method {{AbstractCommandStream.read()}}
is called
in a loop and the flush should be called after last byte. This normally happens
if the loop is not stopped. If another thread marks the
{{AbstractCommandStream}}'s Thread to be closed asynchronously, then the bytes
can be lost in the Thread calling {{read()}} method.
Therefore flushing if stream has been marked for closing it in the intermediate
time between these two threads.
This was on the side of Maven process which sends commands to forked JVM. If
the fork does not receive complete data, even if flushed, nothing special
happens. The fork remains in the state of reading complete command or stops
after timing out.
If {{InputStream}} is closed after marking it then no flush helps of course.
was:
Command reader and command stream refactoring.
Command Stream should flush on stream closed.
> AbstractCommandStream should flush data if another Thread marks the stream
> closed, empty shared buffer.
> ---
>
> Key: SUREFIRE-1380
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1380
> Project: Maven Surefire
> Issue Type: Task
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Reporter: Tibor Digana
>Assignee: Tibor Digana
> Fix For: 2.20.1
>
>
> Another flush is necessary because the method
> {{AbstractCommandStream.read()}} is called
> in a loop and the flush should be called after last byte. This normally
> happens if the loop is not stopped. If another thread marks the
> {{AbstractCommandStream}}'s Thread to be closed asynchronously, then the
> bytes can be lost in the Thread calling {{read()}} method.
> Therefore flushing if stream has been marked for closing it in the
> intermediate time between these two threads.
> This was on the side of Maven process which sends commands to forked JVM. If
> the fork does not receive complete data, even if flushed, nothing special
> happens. The fork remains in the state of reading complete command or stops
> after timing out.
> If {{InputStream}} is closed after marking it then no flush helps of course.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (SUREFIRE-1380) AbstractCommandStream should flush data if another Thread marks the stream closed, empty shared buffer.
[ https://issues.apache.org/jira/browse/SUREFIRE-1380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-1380: --- Summary: AbstractCommandStream should flush data if another Thread marks the stream closed, empty shared buffer. (was: Command stream should flush data anyway and refactoring) > AbstractCommandStream should flush data if another Thread marks the stream > closed, empty shared buffer. > --- > > Key: SUREFIRE-1380 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1380 > Project: Maven Surefire > Issue Type: Task > Components: Maven Failsafe Plugin, Maven Surefire Plugin >Reporter: Tibor Digana >Assignee: Tibor Digana > Fix For: 2.20.1 > > > Command reader and command stream refactoring. > Command Stream should flush on stream closed. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (SUREFIRE-1381) Refactoring in AbstractCommandStream and MasterProcessCommand
[
https://issues.apache.org/jira/browse/SUREFIRE-1381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-1381:
---
Description:
I have removed deprecated method
{code}
@Deprecated
protected final MasterProcessCommand getLastCommand()
{
return lastCommand;
}
{code}
and the variable
{code}
private volatile MasterProcessCommand lastCommand;
{code}
can be inlined in {{read()}} method.
{{MasterProcessCommand}} has method
{code}public byte[] encode( String data ){code}
and uses {{dataBytes.length}} with fixed length of array in three places.
Therefore the refactoring would be to store it to constant {len}}
{code}final int len = dataBytes.length;{code}
and use it in three places as before.
was:
I have removed deprecated method
{code}
@Deprecated
protected final MasterProcessCommand getLastCommand()
{
return lastCommand;
}
{code}
and the variable
{code}
private volatile MasterProcessCommand lastCommand;
{code}
can be inlined in {{read()}} method.
> Refactoring in AbstractCommandStream and MasterProcessCommand
> -
>
> Key: SUREFIRE-1381
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1381
> Project: Maven Surefire
> Issue Type: Task
> Components: process forking
>Reporter: Tibor Digana
>Assignee: Tibor Digana
> Fix For: 2.20.1
>
>
> I have removed deprecated method
> {code}
> @Deprecated
> protected final MasterProcessCommand getLastCommand()
> {
> return lastCommand;
> }
> {code}
> and the variable
> {code}
> private volatile MasterProcessCommand lastCommand;
> {code}
> can be inlined in {{read()}} method.
> {{MasterProcessCommand}} has method
> {code}public byte[] encode( String data ){code}
> and uses {{dataBytes.length}} with fixed length of array in three places.
> Therefore the refactoring would be to store it to constant {len}}
> {code}final int len = dataBytes.length;{code}
> and use it in three places as before.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (SUREFIRE-1381) Refactoring in AbstractCommandStream and MasterProcessCommand
[
https://issues.apache.org/jira/browse/SUREFIRE-1381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-1381:
---
Description:
I have removed deprecated method
{code}
@Deprecated
protected final MasterProcessCommand getLastCommand()
{
return lastCommand;
}
{code}
and the variable
{code}
private volatile MasterProcessCommand lastCommand;
{code}
can be inlined in {{read()}} method.
was:
I have removed deprecated method
{code}
@Deprecated
protected final MasterProcessCommand getLastCommand()
{
return lastCommand;
}
{code}
and the variable
{code}
private volatile MasterProcessCommand lastCommand;
{code}
can be inluned in {{read()}} method.
> Refactoring in AbstractCommandStream and MasterProcessCommand
> -
>
> Key: SUREFIRE-1381
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1381
> Project: Maven Surefire
> Issue Type: Task
> Components: process forking
>Reporter: Tibor Digana
>Assignee: Tibor Digana
> Fix For: 2.20.1
>
>
> I have removed deprecated method
> {code}
> @Deprecated
> protected final MasterProcessCommand getLastCommand()
> {
> return lastCommand;
> }
> {code}
> and the variable
> {code}
> private volatile MasterProcessCommand lastCommand;
> {code}
> can be inlined in {{read()}} method.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (SUREFIRE-1381) Refactoring in AbstractCommandStream and MasterProcessCommand
Tibor Digana created SUREFIRE-1381:
--
Summary: Refactoring in AbstractCommandStream and
MasterProcessCommand
Key: SUREFIRE-1381
URL: https://issues.apache.org/jira/browse/SUREFIRE-1381
Project: Maven Surefire
Issue Type: Task
Components: process forking
Reporter: Tibor Digana
Assignee: Tibor Digana
Fix For: 2.20.1
I have removed deprecated method
{code}
@Deprecated
protected final MasterProcessCommand getLastCommand()
{
return lastCommand;
}
{code}
and the variable
{code}
private volatile MasterProcessCommand lastCommand;
{code}
can be inluned in {{read()}} method.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (SUREFIRE-1376) "The forked VM terminated without properly saying goodbye" when running Surefire in a very deep project structure on Windows
[
https://issues.apache.org/jira/browse/SUREFIRE-1376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana closed SUREFIRE-1376.
--
Resolution: Fixed
https://git-wip-us.apache.org/repos/asf?p=maven-surefire.git;a=commit;h=59c065f5d4a5a9c181ef9ce788b31305886e8592
> "The forked VM terminated without properly saying goodbye" when running
> Surefire in a very deep project structure on Windows
>
>
> Key: SUREFIRE-1376
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1376
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 2.20
> Environment: Windows
>Reporter: Guillaume Boué
>Assignee: Tibor Digana
> Fix For: 2.20.1
>
> Attachments: SUREFIRE-1376-prefix.patch
>
>
> When Surefire is ran on a project under a very long path (exceeding Windows'
> {{MAX_PATH}}), the invocation fails with
> {noformat}
> org.apache.maven.surefire.booter.SurefireBooterForkException: The forked VM
> terminated without properly saying goodbye. VM crash or System.exit called?
> {noformat}
> In the generated dumpstream, there is
> {noformat}
> # Created on 2017-05-28T10:17:09.474
> Error: Unable to access jarfile
> C:\Users\Guillaume\Desktop\surefire-longpath-test-with-windows\surefire-longpath-test-with-windows\surefire-longpath-test-with-windows\surefire-longpath-test-with-windows\surefire-longpath-test-with-windows\surefire-longpath-test-with-windows\target\surefire\surefirebooter2512478076549179739.jar
> {noformat}
> The problem is that the path to the JAR file exceeds the maximum path length
> of 260 characters, and so it cannot be accessed.
> Prepending the path to the JAR file with {{\\?\}}, [as documented
> on
> MSDN|https://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx#maxpath],
> makes the test run again correctly. I've attached a possible patch with this
> approach (SUREFIRE-1376-prefix.patch, that also handles UNC pathnames), but
> perhaps there is a better way to tackle this problem.
> In order to reproduce this, it is possible to create a project under lots of
> different subdirectories, something like:
> {noformat}
> └───surefire-longpath-test-with-windows
> └───surefire-longpath-test-with-windows
> └───surefire-longpath-test-with-windows
> └───surefire-longpath-test-with-windows
> └───surefire-longpath-test-with-windows
> │ pom.xml
> │
> └───src
> └───test
> └───java
> └───Test.java
> {noformat}
> As a side-note, this issue is behind the current Jenkins failures on
> [maven-plugins-ITs-m3.1.x-with-maven-plugin-jdk-1.8_windows|https://builds.apache.org/job/maven-plugins-ITs-m3.1.x-with-maven-plugin-jdk-1.8_windows/3702/]
> when running the ITs on the Assembly Plugin.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (SUREFIRE-1380) Command stream should flush data anyway and refactoring
[ https://issues.apache.org/jira/browse/SUREFIRE-1380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-1380: --- Fix Version/s: 2.20.1 > Command stream should flush data anyway and refactoring > --- > > Key: SUREFIRE-1380 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1380 > Project: Maven Surefire > Issue Type: Task > Components: Maven Failsafe Plugin, Maven Surefire Plugin >Reporter: Tibor Digana >Assignee: Tibor Digana > Fix For: 2.20.1 > > > Command reader and command stream refactoring. > Command Stream should flush on stream closed. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (SUREFIRE-1380) Command stream should flush data anyway and refactoring
Tibor Digana created SUREFIRE-1380: -- Summary: Command stream should flush data anyway and refactoring Key: SUREFIRE-1380 URL: https://issues.apache.org/jira/browse/SUREFIRE-1380 Project: Maven Surefire Issue Type: Task Components: Maven Failsafe Plugin, Maven Surefire Plugin Reporter: Tibor Digana Assignee: Tibor Digana Command reader and command stream refactoring. Command Stream should flush on stream closed. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1379) When rerunning failed tests, I want to be able to set a delay between each attempt, so the whole test suite doesn't fail due to a connection problem to 3rd party ser
[ https://issues.apache.org/jira/browse/SUREFIRE-1379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16035888#comment-16035888 ] Gilberto Torrezan commented on SUREFIRE-1379: - Sorry, putting a delay on `@Before` doesn't solve the problem. First, because I want a delay only between retry attempts, not on regular executions. For example, if I have 10 tests, and all of them run without problems, no delay is inserted. But, if the 9th test fails, and the `rerunFailingTestsCount` property is greater than 0, it will be rerun. And in this case I want it to sleep for some seconds before rerunning again. Second, yes, nobody wants to slow down tests. That's why my proposal is about creating a property for the plugin, let's say `timeBetweenRerunAttempts` (or a better name), that would be 0 by default. No tests would be impacted unless you specify so. Third, and that's indeed just my problem: Currently I have more than 1300 tests in my application, and since we already manage retries of failed tests by using the failsafe plugin (and the `rerunFailingTestsCount` property), it looks like a good place to also configure this delay I've mentioned. It's totally impractical to go test-by-test and introduce the delay by hand (also because it doesn't actually solve the problem, see above). As a side-note, not related to the issue at hand: can you point me instructions on how to properly submit issues to this project? I've tried using a [job story format|https://blog.intercom.com/using-job-stories-design-features-ui-ux/], but it caused more confusion than it helped. Thanks! > When rerunning failed tests, I want to be able to set a delay between each > attempt, so the whole test suite doesn't fail due to a connection problem to > 3rd party services. > --- > > Key: SUREFIRE-1379 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1379 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Failsafe Plugin >Affects Versions: 2.20 >Reporter: Gilberto Torrezan >Assignee: Tibor Digana > > Some of my integration tests require access to 3rd party services that run in > other machines, and sometimes those services stop responding due to network > problems. > I want to be able to set a delay between each attempt to rerun a failed > test, instead of rerunning everything in the same second, so tests that fail > due to connection problems can have better chances of succeed. > Waiting 5 seconds between attempts, in my case, is way cheaper than rerunning > everything again. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
