[GitHub] [maven-surefire] Tibor17 edited a comment on issue #240: [SUREFIRE-1658] TCP/IP Channel for forked Surefire JVM. Extensions API and SPI. Polymorphism for remote and local process communicatio
Tibor17 edited a comment on issue #240: [SUREFIRE-1658] TCP/IP Channel for forked Surefire JVM. Extensions API and SPI. Polymorphism for remote and local process communication. URL: https://github.com/apache/maven-surefire/pull/240#issuecomment-587231574 @eolivelli @jon-bell We can maybe write some integration test and we can start testing on our custom projects. Now the TCP connector can be enabled in the plugin configuration easily like this: ``` ``` Yet the default behavior is not changed. It is a legacy pipes controlled by `LegacyForkNodeFactory`. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-surefire] Tibor17 commented on a change in pull request #240: [SUREFIRE-1658] TCP/IP Channel for forked Surefire JVM. Extensions API and SPI. Polymorphism for remote and local process
Tibor17 commented on a change in pull request #240: [SUREFIRE-1658] TCP/IP Channel for forked Surefire JVM. Extensions API and SPI. Polymorphism for remote and local process communication. URL: https://github.com/apache/maven-surefire/pull/240#discussion_r380418202 ## File path: Jenkinsfile ## @@ -35,7 +35,7 @@ final def mavens = env.BRANCH_NAME == 'master' ? ['3.6.x', '3.2.x'] : ['3.6.x'] // all non-EOL versions and the first EA final def jdks = [14, 13, 11, 8, 7] -final def options = ['-e', '-V', '-B', '-nsu', '-P', 'run-its'] +final def options = ['-e', '-V', '-B', '-nsu'] Review comment: Maybe wanted to avoid some annoying build failures that time ;-) But now it is okay. Pls see the Jenkinsfile again. There is wider history of artifacts, statistics enabled in Jenkinsfile. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-surefire] Tibor17 edited a comment on issue #240: [SUREFIRE-1658] TCP/IP Channel for forked Surefire JVM. Extensions API and SPI. Polymorphism for remote and local process communicatio
Tibor17 edited a comment on issue #240: [SUREFIRE-1658] TCP/IP Channel for forked Surefire JVM. Extensions API and SPI. Polymorphism for remote and local process communication. URL: https://github.com/apache/maven-surefire/pull/240#issuecomment-587231574 @eolivelli @jon-bell We can maybe write some integration test and we can start testing on our custom projects. Now the TCP connector can be enabled in the plugin configuration easily like this: ``` ``` This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-surefire] Tibor17 commented on issue #240: [SUREFIRE-1658] TCP/IP Channel for forked Surefire JVM. Extensions API and SPI. Polymorphism for remote and local process communication.
Tibor17 commented on issue #240: [SUREFIRE-1658] TCP/IP Channel for forked Surefire JVM. Extensions API and SPI. Polymorphism for remote and local process communication. URL: https://github.com/apache/maven-surefire/pull/240#issuecomment-587231574 @eolivelli @jon-bell We can maybe write some integration test and we can start testing on our custom projects. Now the TCP connector can be enabled in the plugin configuration easily like this: ``` ``` This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (SUREFIRE-1751) Surefire report shows flaky tests as failures
[
https://issues.apache.org/jira/browse/SUREFIRE-1751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17038718#comment-17038718
]
Tibor Digana commented on SUREFIRE-1751:
In your real test you have got:
Errors: 1, Failures: 7
Where these numbers come from? They should be zeros and they were the post
results of flakes?
So the XML provided looks too simple to break this test with
TestSuiteXmlParser. The XML should be more realistic in order to provocate the
bug as we can see it in the HTML report.
> Surefire report shows flaky tests as failures
> -
>
> Key: SUREFIRE-1751
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1751
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.0.0-M4
>Reporter: Anu
>Priority: Critical
> Attachments: TEST-com.test.Flakes.xml, Test.zip,
> image-2020-02-13-11-41-03-906.png
>
>
> We have been using maven-surefire-plugin in 2.22.1 and Junit4.13 for our
> testing. Now we are trying to upgrade junit to junit5 and saw that the
> r{color:#6a8759}erunFailingTestsCount parameter isn't working with surefire
> plugin version. I upgraded surefire to 3.0.0.M4 and verified that the failing
> tests are now being retried. But the issue is flaky tests show up in the
> report as Failures.
> {color}
>
> {color:#6a8759}ie. the log shows
> {color}
> [WARNING] Tests run: 10455, Failures: 0, Errors: 0, Skipped: 993, Flakes: 10
>
> But the actual surefire report shows like below
> !image-2020-02-13-11-41-03-906.png!
>
> This is blocking our junit5 upgrade task. Can you please provide a fix for
> this at the earliest? Please let me know if you need anything else from me to
> help with the investigation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MJAVADOC-639) aggregate should use all requires static from maven modules
[ https://issues.apache.org/jira/browse/MJAVADOC-639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17038703#comment-17038703 ] Olivier Lamy edited comment on MJAVADOC-639 at 2/18/20 1:02 AM: [~rfscholte] your it works because the requires static is a module part of the reactor. but for a dependency it doesn't :) see attached IT. was (Author: olamy): [~rfscholte] your it works because the requires static is a module part of the reactor. but for a dependency it doesn't :) > aggregate should use all requires static from maven modules > --- > > Key: MJAVADOC-639 > URL: https://issues.apache.org/jira/browse/MJAVADOC-639 > Project: Maven Javadoc Plugin > Issue Type: Bug > Components: javadoc >Reporter: Olivier Lamy >Assignee: Olivier Lamy >Priority: Major > Fix For: 3.2.0 > > Attachments: MJAVADOC-639_aggr_static_modulepath.zip, > MJAVADOC-639_requires_ignored.zip > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MJAVADOC-639) aggregate should use all requires static from maven modules
[ https://issues.apache.org/jira/browse/MJAVADOC-639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated MJAVADOC-639: -- Attachment: MJAVADOC-639_requires_ignored.zip > aggregate should use all requires static from maven modules > --- > > Key: MJAVADOC-639 > URL: https://issues.apache.org/jira/browse/MJAVADOC-639 > Project: Maven Javadoc Plugin > Issue Type: Bug > Components: javadoc >Reporter: Olivier Lamy >Assignee: Olivier Lamy >Priority: Major > Fix For: 3.2.0 > > Attachments: MJAVADOC-639_aggr_static_modulepath.zip, > MJAVADOC-639_requires_ignored.zip > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-surefire] Tibor17 edited a comment on issue #240: [SUREFIRE-1658] TCP/IP Channel for forked Surefire JVM. Extensions API and SPI. Polymorphism for remote and local process communicatio
Tibor17 edited a comment on issue #240: [SUREFIRE-1658] TCP/IP Channel for forked Surefire JVM. Extensions API and SPI. Polymorphism for remote and local process communication. URL: https://github.com/apache/maven-surefire/pull/240#issuecomment-587226076 @eolivelli yes, it's a lot of changes but we do not change the core principle of the plugin. The reason why we do this is the fact that we are in the point where fixes are not trivial with one or two changed classes. If we simply turned everyhing to TCP without backing up the pipes, we would be in troubles. Therefore this strategy with extensions gives us a chance to alter the tcp/pipes anytime. So i would like to keep the pipes in these milestone versions until tcp is bulletproof. Meanwhile the users of Karaf may alter the behavior to tcp in their plugin configuration and provide us with the feedback. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-surefire] Tibor17 commented on issue #240: [SUREFIRE-1658] TCP/IP Channel for forked Surefire JVM. Extensions API and SPI. Polymorphism for remote and local process communication.
Tibor17 commented on issue #240: [SUREFIRE-1658] TCP/IP Channel for forked Surefire JVM. Extensions API and SPI. Polymorphism for remote and local process communication. URL: https://github.com/apache/maven-surefire/pull/240#issuecomment-587226076 @eolivelli yes, it's a lot of changes but we do not change the core principle of the plugin. The reason why we do this is the fact that we are in the point where fixes are not trivial with one or two changed classes. If we simply turned everyhing to TCP without backing up the pipes, we would be in troubles. Therefore this strategy with extensions gives us a changes to alter the tcp/pipes. So i would like to keep the pipes in these milestone versions until tcp is bulletproof. Meanwhile the users of Karaf may alter the behavior to tcp in their plugin configuration and provide us with the feedback. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (MJAVADOC-639) aggregate should use all requires static from maven modules
[ https://issues.apache.org/jira/browse/MJAVADOC-639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17038703#comment-17038703 ] Olivier Lamy commented on MJAVADOC-639: --- [~rfscholte] your it works because the requires static is a module part of the reactor. but for a dependency it doesn't :) > aggregate should use all requires static from maven modules > --- > > Key: MJAVADOC-639 > URL: https://issues.apache.org/jira/browse/MJAVADOC-639 > Project: Maven Javadoc Plugin > Issue Type: Bug > Components: javadoc >Reporter: Olivier Lamy >Assignee: Olivier Lamy >Priority: Major > Fix For: 3.2.0 > > Attachments: MJAVADOC-639_aggr_static_modulepath.zip > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-invoker-plugin] slawekjaranowski opened a new pull request #14: [MINVOKER-255] support environmentVariable in invokerPropertiesFile
slawekjaranowski opened a new pull request #14: [MINVOKER-255] support environmentVariable in invokerPropertiesFile URL: https://github.com/apache/maven-invoker-plugin/pull/14 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Closed] (MSHARED-843) Provide artifacts in CollectorResult when collectDependencies
[ https://issues.apache.org/jira/browse/MSHARED-843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MSHARED-843. -- Fix Version/s: maven-artifact-transfer-0.12.1 Assignee: Robert Scholte Resolution: Fixed Fixed in [a2505edefaf797f6492dc8365e0af8fab56c750a|https://gitbox.apache.org/repos/asf?p=maven-artifact-transfer.git;a=commit;h=a2505edefaf797f6492dc8365e0af8fab56c750a] Thanks for the patch! > Provide artifacts in CollectorResult when collectDependencies > -- > > Key: MSHARED-843 > URL: https://issues.apache.org/jira/browse/MSHARED-843 > Project: Maven Shared Components > Issue Type: New Feature > Components: maven-artifact-transfer >Reporter: Pim Moerenhout >Assignee: Robert Scholte >Priority: Minor > Fix For: maven-artifact-transfer-0.12.1 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > To resolve MDEP-648, to list all repositories and the POM's where these > repositories are defined, the collectDependencies in DependencyCollector > should also return the found artifact without resolving them. > The CollectorResult could define the interface: > List getArtifacts() -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-surefire] Tibor17 commented on issue #240: [SUREFIRE-1658] TCP/IP Channel for forked Surefire JVM. Extensions API and SPI. Polymorphism for remote and local process communication.
Tibor17 commented on issue #240: [SUREFIRE-1658] TCP/IP Channel for forked Surefire JVM. Extensions API and SPI. Polymorphism for remote and local process communication. URL: https://github.com/apache/maven-surefire/pull/240#issuecomment-587173161 @eolivelli Pls review the last commit. It is the changes made upon your request. thx This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (WAGON-453) java.net.useSystemProxies don't work with wagon-http-lightweight
[
https://issues.apache.org/jira/browse/WAGON-453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17038651#comment-17038651
]
jycr commented on WAGON-453:
Sorry for my much too late response. I had a (very) long break.
Regarding property {{java.net.useSystemProxies=true}}, it's the same behavior
if I pass it with MAVEN_OPTS, or via command line.
I don't configure any proxy in {{settings.xml}}
Standard/default HTTP wagon (based on HttpClient) don't work (exception:
{{Malformed reply from SOCKS server}}).
I suspect that NTLM implementation in HttpClient [is
buggy.|https://codepen.io/ugbandula/post/how-to-configure-maven-to-work-with-ntlm-proxies]
I have successfully tested following patch:
[^0001-WAGON-453-Fix-java.net.useSystemProxies-don-t-work-w.patch]
> java.net.useSystemProxies don't work with wagon-http-lightweight
>
>
> Key: WAGON-453
> URL: https://issues.apache.org/jira/browse/WAGON-453
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-http-lightweight
>Affects Versions: 2.10
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T17:41:47+01:00)
> Java version: 1.8.0_74, vendor: Oracle Corporation
> Default locale: fr_FR, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos"
>Reporter: jycr
>Priority: Blocker
> Attachments:
> 0001-WAGON-453-Fix-java.net.useSystemProxies-don-t-work-w.patch
>
>
> In my job, we must use a "corporate proxy" with "NTLM+SPNEGO authentication"
> to access Internet.
> Unfortunately, we haven't got any nominative proxy credential because Windows
> use current user session to authenticate against proxy (we we login to
> Windows session with a smart card).
> The only way for Java application to connect to internet is to launch JVM
> with {{-Djava.net.useSystemProxies=true}} standard parameter.
> It work perfectly with "standard" URLConnection , but unfortunately not with
> wagon-http-lightweight.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (WAGON-453) java.net.useSystemProxies don't work with wagon-http-lightweight
[
https://issues.apache.org/jira/browse/WAGON-453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
jycr updated WAGON-453:
---
Attachment: 0001-WAGON-453-Fix-java.net.useSystemProxies-don-t-work-w.patch
> java.net.useSystemProxies don't work with wagon-http-lightweight
>
>
> Key: WAGON-453
> URL: https://issues.apache.org/jira/browse/WAGON-453
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-http-lightweight
>Affects Versions: 2.10
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T17:41:47+01:00)
> Java version: 1.8.0_74, vendor: Oracle Corporation
> Default locale: fr_FR, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos"
>Reporter: jycr
>Priority: Blocker
> Attachments:
> 0001-WAGON-453-Fix-java.net.useSystemProxies-don-t-work-w.patch
>
>
> In my job, we must use a "corporate proxy" with "NTLM+SPNEGO authentication"
> to access Internet.
> Unfortunately, we haven't got any nominative proxy credential because Windows
> use current user session to authenticate against proxy (we we login to
> Windows session with a smart card).
> The only way for Java application to connect to internet is to launch JVM
> with {{-Djava.net.useSystemProxies=true}} standard parameter.
> It work perfectly with "standard" URLConnection , but unfortunately not with
> wagon-http-lightweight.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MSHARED-843) Provide artifacts in CollectorResult when collectDependencies
[ https://issues.apache.org/jira/browse/MSHARED-843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17038647#comment-17038647 ] Hudson commented on MSHARED-843: Build succeeded in Jenkins: Maven TLP » maven-artifact-transfer » MSHARED-843 #4 See https://builds.apache.org/job/maven-box/job/maven-artifact-transfer/job/MSHARED-843/4/ > Provide artifacts in CollectorResult when collectDependencies > -- > > Key: MSHARED-843 > URL: https://issues.apache.org/jira/browse/MSHARED-843 > Project: Maven Shared Components > Issue Type: New Feature > Components: maven-artifact-transfer >Reporter: Pim Moerenhout >Priority: Minor > Time Spent: 1h > Remaining Estimate: 0h > > To resolve MDEP-648, to list all repositories and the POM's where these > repositories are defined, the collectDependencies in DependencyCollector > should also return the found artifact without resolving them. > The CollectorResult could define the interface: > List getArtifacts() -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MCHANGELOG-151) Migrate plugin to Maven 3.0.5
[ https://issues.apache.org/jira/browse/MCHANGELOG-151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz updated MCHANGELOG-151: Description: * Replacing usage of deprecated APIs * Renaming the packages to org.apache.maven.plugins * Removing Maven 2 specific code * Fixing Javadoc comments * Removing the use of raw types where possible > Migrate plugin to Maven 3.0.5 > - > > Key: MCHANGELOG-151 > URL: https://issues.apache.org/jira/browse/MCHANGELOG-151 > Project: Maven Changelog Plugin > Issue Type: Improvement >Reporter: Sylwester Lachiewicz >Priority: Major > > * Replacing usage of deprecated APIs > * Renaming the packages to org.apache.maven.plugins > * Removing Maven 2 specific code > * Fixing Javadoc comments > * Removing the use of raw types where possible -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (MCHANGELOG-151) Migrate plugin to Maven 3.0.5
Sylwester Lachiewicz created MCHANGELOG-151: --- Summary: Migrate plugin to Maven 3.0.5 Key: MCHANGELOG-151 URL: https://issues.apache.org/jira/browse/MCHANGELOG-151 Project: Maven Changelog Plugin Issue Type: Improvement Reporter: Sylwester Lachiewicz -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MCHANGELOG-150) Upgrade JUnit to 4.13
[ https://issues.apache.org/jira/browse/MCHANGELOG-150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz closed MCHANGELOG-150. --- Resolution: Fixed > Upgrade JUnit to 4.13 > - > > Key: MCHANGELOG-150 > URL: https://issues.apache.org/jira/browse/MCHANGELOG-150 > Project: Maven Changelog Plugin > Issue Type: Dependency upgrade >Reporter: Sylwester Lachiewicz >Priority: Minor > Fix For: 2.4.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MCHANGELOG-150) Upgrade JUnit to 4.13
[ https://issues.apache.org/jira/browse/MCHANGELOG-150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz updated MCHANGELOG-150: Fix Version/s: 2.4.0 > Upgrade JUnit to 4.13 > - > > Key: MCHANGELOG-150 > URL: https://issues.apache.org/jira/browse/MCHANGELOG-150 > Project: Maven Changelog Plugin > Issue Type: Dependency upgrade >Reporter: Sylwester Lachiewicz >Priority: Minor > Fix For: 2.4.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MCHANGELOG-150) Upgrade JUnit to 4.13
[ https://issues.apache.org/jira/browse/MCHANGELOG-150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17038623#comment-17038623 ] Sylwester Lachiewicz commented on MCHANGELOG-150: - Done in [8cdbbf3ede0591e1fb096d2b6ef0bf8778d043c3|https://gitbox.apache.org/repos/asf?p=maven-changelog-plugin.git;a=commit;h=8cdbbf3ede0591e1fb096d2b6ef0bf8778d043c3] > Upgrade JUnit to 4.13 > - > > Key: MCHANGELOG-150 > URL: https://issues.apache.org/jira/browse/MCHANGELOG-150 > Project: Maven Changelog Plugin > Issue Type: Dependency upgrade >Reporter: Sylwester Lachiewicz >Priority: Minor > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MCHANGELOG-150) Upgrade JUnit to 4.13
[ https://issues.apache.org/jira/browse/MCHANGELOG-150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17038620#comment-17038620 ] Hudson commented on MCHANGELOG-150: --- Build succeeded in Jenkins: Maven TLP » maven-changelog-plugin » master #25 See https://builds.apache.org/job/maven-box/job/maven-changelog-plugin/job/master/25/ > Upgrade JUnit to 4.13 > - > > Key: MCHANGELOG-150 > URL: https://issues.apache.org/jira/browse/MCHANGELOG-150 > Project: Maven Changelog Plugin > Issue Type: Dependency upgrade >Reporter: Sylwester Lachiewicz >Priority: Minor > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MCHANGELOG-149) Upgrade maven-plugins pom to version 34
[ https://issues.apache.org/jira/browse/MCHANGELOG-149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz closed MCHANGELOG-149. --- Resolution: Fixed > Upgrade maven-plugins pom to version 34 > --- > > Key: MCHANGELOG-149 > URL: https://issues.apache.org/jira/browse/MCHANGELOG-149 > Project: Maven Changelog Plugin > Issue Type: Dependency upgrade >Reporter: Sylwester Lachiewicz >Assignee: Sylwester Lachiewicz >Priority: Major > Fix For: 2.4.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (MCHANGELOG-150) Upgrade JUnit to 4.13
Sylwester Lachiewicz created MCHANGELOG-150: --- Summary: Upgrade JUnit to 4.13 Key: MCHANGELOG-150 URL: https://issues.apache.org/jira/browse/MCHANGELOG-150 Project: Maven Changelog Plugin Issue Type: Dependency upgrade Reporter: Sylwester Lachiewicz -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MCHANGELOG-149) Upgrade maven-plugins pom to version 34
[ https://issues.apache.org/jira/browse/MCHANGELOG-149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17038607#comment-17038607 ] Hudson commented on MCHANGELOG-149: --- Build succeeded in Jenkins: Maven TLP » maven-changelog-plugin » master #24 See https://builds.apache.org/job/maven-box/job/maven-changelog-plugin/job/master/24/ > Upgrade maven-plugins pom to version 34 > --- > > Key: MCHANGELOG-149 > URL: https://issues.apache.org/jira/browse/MCHANGELOG-149 > Project: Maven Changelog Plugin > Issue Type: Dependency upgrade >Reporter: Sylwester Lachiewicz >Assignee: Sylwester Lachiewicz >Priority: Major > Fix For: 2.4.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MCHANGELOG-149) Upgrade maven-plugins pom to version 34
[ https://issues.apache.org/jira/browse/MCHANGELOG-149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17038604#comment-17038604 ] Sylwester Lachiewicz commented on MCHANGELOG-149: - Done in [20a78c04b264aba4537561e8c6e44645cd31568d|https://gitbox.apache.org/repos/asf?p=maven-changelog-plugin.git;a=commit;h=20a78c04b264aba4537561e8c6e44645cd31568d] > Upgrade maven-plugins pom to version 34 > --- > > Key: MCHANGELOG-149 > URL: https://issues.apache.org/jira/browse/MCHANGELOG-149 > Project: Maven Changelog Plugin > Issue Type: Dependency upgrade >Reporter: Sylwester Lachiewicz >Assignee: Sylwester Lachiewicz >Priority: Major > Fix For: 2.4.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MCHANGELOG-149) Upgrade maven-plugins pom to version 34
[ https://issues.apache.org/jira/browse/MCHANGELOG-149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz updated MCHANGELOG-149: Fix Version/s: 2.4.0 > Upgrade maven-plugins pom to version 34 > --- > > Key: MCHANGELOG-149 > URL: https://issues.apache.org/jira/browse/MCHANGELOG-149 > Project: Maven Changelog Plugin > Issue Type: Dependency upgrade >Reporter: Sylwester Lachiewicz >Assignee: Sylwester Lachiewicz >Priority: Major > Fix For: 2.4.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (MCHANGELOG-149) Upgrade maven-plugins pom to version 34
[ https://issues.apache.org/jira/browse/MCHANGELOG-149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz reassigned MCHANGELOG-149: --- Assignee: Sylwester Lachiewicz > Upgrade maven-plugins pom to version 34 > --- > > Key: MCHANGELOG-149 > URL: https://issues.apache.org/jira/browse/MCHANGELOG-149 > Project: Maven Changelog Plugin > Issue Type: Dependency upgrade >Reporter: Sylwester Lachiewicz >Assignee: Sylwester Lachiewicz >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (MCHANGELOG-149) Upgrade maven-plugins pom to version 34
Sylwester Lachiewicz created MCHANGELOG-149: --- Summary: Upgrade maven-plugins pom to version 34 Key: MCHANGELOG-149 URL: https://issues.apache.org/jira/browse/MCHANGELOG-149 Project: Maven Changelog Plugin Issue Type: Dependency upgrade Reporter: Sylwester Lachiewicz -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven] JLLeitschuh commented on issue #323: [SECURITY] Use HTTPS to resolve dependencies in Maven Build
JLLeitschuh commented on issue #323: [SECURITY] Use HTTPS to resolve dependencies in Maven Build URL: https://github.com/apache/maven/pull/323#issuecomment-587143025 This is an automated PR: 'Allow edits from maintainers' is checked. If you are able to do so, I'd appreciate it if you could resolve this from here. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (SUREFIRE-1752) Implement new value for the "parallel" config element (e.g. "categories")
[
https://issues.apache.org/jira/browse/SUREFIRE-1752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17038597#comment-17038597
]
Tibor Digana commented on SUREFIRE-1752:
[~stephan]
We, surefire, do not "execute" the tests.
It is the JUnit library.
We only instantiate it and pass the bunch of classes into it.
Then we listen to the events coming from the JUnit lib.
This is the way we "filter" your categorized test classes/methods upon [JUnit's
filter|https://junit.org/junit4/javadoc/4.12/org/junit/runners/ParentRunner.html#filter(org.junit.runner.manipulation.Filter)].
Pls see our
[implementation|https://github.com/apache/maven-surefire/blob/master/surefire-providers/common-junit48/src/main/java/org/apache/maven/surefire/common/junit48/CombinedCategoryFilter.java].
Our
[ParallelComputer|https://github.com/apache/maven-surefire/blob/master/surefire-providers/surefire-junit47/src/main/java/org/apache/maven/surefire/junitcore/pc/ParallelComputerBuilder.java#L693]
can distinguish between
[Suite|https://junit.org/junit4/javadoc/latest/org/junit/runners/Suite.html]
and ordinal
[ParentRunner|https://junit.org/junit4/javadoc/latest/org/junit/runners/ParentRunner.html].
That's the reason why we can specify "parallel" and some combinations of
suite, classes and methods.
In my opinion, you should become our contributor, think about the JUnit
internals (same with my professional experience), and then we can together
adapt the ParallelCompuet in Surefire.
Currently, we are working on [the
PR|https://github.com/apache/maven-surefire/pull/240/] and I would be very
happy if you would contribute to the project with your issue. Feel free to dig
into JUnit and Surefire itself and provide some code proposals for Surefire.
> Implement new value for the "parallel" config element (e.g. "categories")
> -
>
> Key: SUREFIRE-1752
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1752
> Project: Maven Surefire
> Issue Type: New Feature
> Components: Junit 4.7+ (parallel) support
>Affects Versions: 3.0.0-M4
>Reporter: Stephan Bauer
>Priority: Major
>
> According to
> [http://maven.apache.org/surefire/maven-failsafe-plugin/integration-test-mojo.html]
> the "parallel" configuration element currently only supports the following
> values:
> * suites
> * suitesAndClasses
> * suitesAndMethods
> * classesAndMethods
> We have a huge multi-module application with integrationtests living in many
> separate integrationtest-modules. Until now, all the integrationtests were
> executed through one additional central integrationtest-module, that
> contained the testsuite definitions. Each testsuites consists of tests from
> different integrationtest-modules.
> Example:
> * Testsuite A refers to tests from integrationtest-modules M1, M2 and M3
> * Testsuite B refers to tests from integrationtest-modules M1, M3 and M4
> * Testsuite C refers to tests from integrationtest-modules M2, M3 and M4
> (all testsuites are disjoint, which means that each test belongs to exactly
> one testsuite)
> Until now, the different testsuites were configured to be run in parallel, by
> using:
> {code:java}
>
> org.apache.maven.plugins
> maven-failsafe-plugin
> 3.0.0-M3
>
> suites
> 5
>
>
> {code}
> The central integrationtest module occurs to be more or less a hack, because
> you need to duplicate all dependencies from all integrationtest modules. This
> results in the fact, that any integrationtest is not executed with the
> classpath of its own module but of the central module.
> This turns out to be problematic sometimes (PS: furthermore we couldn't
> manage to configure the jacoco-maven-plugin properly so that the coverage of
> all the integrationtests could not measured correcty).
> The idea to solve this is to replace the Testsuites with the Junit4
> Categories. Unfortunately, the failsafe-plugin does not provide a value for
> the "parallel" config element based on the Junit categories. The consequence
> is, that all integrationtests now run serially which takes far too long and
> thus is not acceptable for us.
> PS: Another alternative solution would be to upgrade to Junit5 and have
> parallelization based on the new "Tag" element. But obviously there is no
> such support available either.
> PS-2: sorry for possibly using the wrong priority. Of course this is rather
> important for us, because it keeps us from moving away from the old central
> integrationtest module which is very annoying. I'm wondering that nobody else
> seems to have the same requirement as I can't imagine, that our usecase with
> testsuites spanning tests from different integrationtest modules is so
> exotic...
> Best regards,
[GitHub] [maven-archetype] JLLeitschuh commented on issue #37: [SECURITY] Use HTTPS to resolve dependencies in Maven Build
JLLeitschuh commented on issue #37: [SECURITY] Use HTTPS to resolve dependencies in Maven Build URL: https://github.com/apache/maven-archetype/pull/37#issuecomment-587140114 Was this resolved? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Updated] (MNG-6866) PluginDescriptorBuilder build method very long
[ https://issues.apache.org/jira/browse/MNG-6866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arne Lewinski updated MNG-6866: --- Priority: Minor (was: Major) > PluginDescriptorBuilder build method very long > -- > > Key: MNG-6866 > URL: https://issues.apache.org/jira/browse/MNG-6866 > Project: Maven > Issue Type: Improvement > Components: core >Reporter: Arne Lewinski >Priority: Minor > > The build method of the class ""PluginDescriptorBuilder" is very long. > I suggest to extract several methods and harmonize the methodolgy to set all > values. It can follows the strict concept: extracting the necessary element > from the PlexusConfiguration and setting it on the PluginDescriptor. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (SUREFIRE-1134) Take list of tests from file (-Dtest has upper limits for comma-separated list of tests)
[
https://issues.apache.org/jira/browse/SUREFIRE-1134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17038580#comment-17038580
]
Daniel Elsner edited comment on SUREFIRE-1134 at 2/17/20 7:22 PM:
--
@Tibor You are right, it is possible to select specific *test classes* with
`-Dsurefire.includesFile` etc., but it is not possible to select specific *test
cases*, e.g., test methods with `@Test` annotation in JUnit. This is a
limitation, as one might only want to include specific test cases rather than
entire test classes.
It is implemented here:
[https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java#L2092]
Of course, you can still use `-Dtest` to specify methods, but this has its
restrictions, as for example in Windows environments, you cannot have more than
8192 characters in a single command (e.g. powershell/cmd.exe). Hence, selecting
a few hundred tests with long package names will fail.
Maybe we could either remove the check for method names in
`-Dsurefire.includesFile` or add `-DtestListFile=testsToRun.txt` as @Paul
suggested above.
If you think I have a point, I would also volunteer to implement this feature
as I could really use it for my software testing research.
was (Author: delsner):
@Tibor You are right, it is possible to select specific *test classes* with
`-Dsurefire.includesFile` etc., but it is not possible to select specific *test
cases*, e.g., test methods with `@Test` annotation in JUnit. This is a
limitation, as one might only want to include specific test cases rather than
entire test classes.
It is implemented here:
[https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java#L2092]
Of course, you can still use `-Dtest` to specify methods, but this has its
restrictions, as for example in Windows environments, you cannot have more than
8192 characters in a single command (e.g. powershell/cmd.exe). Hence, selecting
a few hundred tests with long package names will fail.
Maybe we could either remove the check for method names in
`-Dsurefire.includesFile` or add `-DtestListFile=testsToRun.txt` as @Paul
suggested above.
If you think I have a point, I would also volunteer to implement this feature.
> Take list of tests from file (-Dtest has upper limits for comma-separated
> list of tests)
>
>
> Key: SUREFIRE-1134
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1134
> Project: Maven Surefire
> Issue Type: New Feature
>Reporter: Paul Hammant
>Assignee: Tibor Digana
>Priority: Minor
> Fix For: 2.19
>
>
> -Dtest=TestOne,foo.BarTest is the way to go for constraining surefire to a
> list of tests. There are upper limits to that in the context of command line
> arguments.
> Could we additionally have:
> {panel:title=Example mvn
> param|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#CE}
> -DtestListFile=testsToRun.txt
> {panel}
> Also for Failsafe:
> {panel:title=Example mvn
> param|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#CE}
> -Dit.testListFile=testsToRun.txt
> {panel}
> Yes, I'd be rewriting testsToRun.txt for my use case, just before invoking
> Maven.
> Refer
> http://paulhammant.com/2015/01/11/reducing-test-times-by-only-running-impacted-tests/
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (SUREFIRE-1134) Take list of tests from file (-Dtest has upper limits for comma-separated list of tests)
[
https://issues.apache.org/jira/browse/SUREFIRE-1134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17038580#comment-17038580
]
Daniel Elsner edited comment on SUREFIRE-1134 at 2/17/20 7:21 PM:
--
@Tibor You are right, it is possible to select specific *test classes* with
`-Dsurefire.includesFile` etc., but it is not possible to select specific *test
cases*, e.g., test methods with `@Test` annotation in JUnit. This is a
limitation, as one might only want to include specific test cases rather than
entire test classes.
It is implemented here:
[https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java#L2092]
Of course, you can still use `-Dtest` to specify methods, but this has its
restrictions, as for example in Windows environments, you cannot have more than
8192 characters in a single command (e.g. powershell/cmd.exe). Hence, selecting
a few hundred tests with long package names will fail.
Maybe we could either remove the check for method names in
`-Dsurefire.includesFile` or add `-DtestListFile=testsToRun.txt` as @Paul
suggested above.
If you think I have a point, I would also volunteer to implement this feature.
was (Author: delsner):
@Tibor You are right, it is possible to select specific *test classes* with
`-Dsurefire.includesFile` etc., but it is not possible to select specific *test
cases*, e.g., test methods with `@Test` annotation in JUnit. This is a
limitation, as one might only want to include specific test cases rather than
entire test classes.
It is implemented here:
[https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java#L2092]
Of course, you can still use `-Dtest` to specify methods, but this has its
restrictions, as for example in Windows environments, you cannot have more than
8192 characters in a single command (e.g. powershell/cmd.exe). Hence, selecting
a few hundred tests with long package names will fail.
Maybe we could either remove the check for method names in
`-Dsurefire.includesFile` or add `-DtestListFile=testsToRun.txt` as @Paul
suggested above.
> Take list of tests from file (-Dtest has upper limits for comma-separated
> list of tests)
>
>
> Key: SUREFIRE-1134
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1134
> Project: Maven Surefire
> Issue Type: New Feature
>Reporter: Paul Hammant
>Assignee: Tibor Digana
>Priority: Minor
> Fix For: 2.19
>
>
> -Dtest=TestOne,foo.BarTest is the way to go for constraining surefire to a
> list of tests. There are upper limits to that in the context of command line
> arguments.
> Could we additionally have:
> {panel:title=Example mvn
> param|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#CE}
> -DtestListFile=testsToRun.txt
> {panel}
> Also for Failsafe:
> {panel:title=Example mvn
> param|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#CE}
> -Dit.testListFile=testsToRun.txt
> {panel}
> Yes, I'd be rewriting testsToRun.txt for my use case, just before invoking
> Maven.
> Refer
> http://paulhammant.com/2015/01/11/reducing-test-times-by-only-running-impacted-tests/
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1751) Surefire report shows flaky tests as failures
[
https://issues.apache.org/jira/browse/SUREFIRE-1751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17038582#comment-17038582
]
Anu commented on SUREFIRE-1751:
---
Thanks [~tibordigana]. I tried creating a test method in the class like below
and ran the test with [^TEST-com.test.Flakes.xml] . The test passed (showed
correct number of tests, failures, flakes etc)
{code:java}
@Test
public void successfulSurefireTestReportWithFlakes() throws Exception {
TestSuiteXmlParser parser = new TestSuiteXmlParser( consoleLogger );
File surefireReport = new File(
"src/test/resources/junit-pathWithÜmlaut/TEST-com.test.Flakes.xml" );
assumeTrue( surefireReport.isFile() );
Collection suites = parser.parse(
surefireReport.getCanonicalPath() );
assertNotNull( suites );
assertEquals( 1, suites.size() );
ReportTestSuite suite = suites.iterator().next();
assertThat( suite.getNumberOfTests(), is( 1 ) );
assertEquals( 1, suite.getNumberOfTests() );
assertEquals( 1, suite.getNumberOfFlakes() );
assertEquals( 0, suite.getNumberOfFailures() );
assertEquals( 0, suite.getNumberOfErrors() );
assertEquals( 0, suite.getNumberOfSkipped() );
assertThat( suite.getFullClassName(), is( "com.test.Flakes" ) );
assertThat( suite.getPackageName(), is( "com.test" ) );
assertThat( suite.getName(), is( "Flakes" ) );
ReportTestCase test = suite.getTestCases().iterator().next();
assertTrue( test.isSuccessful() );
assertNull( test.getFailureDetail() );
assertNull( test.getFailureErrorLine() );
assertNull( test.getFailureType() );
assertThat( test.getFullClassName(), is( "com.test.Flakes" ) );
assertThat( test.getClassName(), is( "Flakes" ) );
assertThat( test.getName(), is( "run" ) );
assertThat( test.getFullName(), is( "com.test.Flakes.run" ) );
} {code}
I am new to the github world, so I am not sure how to commit this test to the
repository.
can you please help on how to proceed?
> Surefire report shows flaky tests as failures
> -
>
> Key: SUREFIRE-1751
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1751
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.0.0-M4
>Reporter: Anu
>Priority: Critical
> Attachments: TEST-com.test.Flakes.xml, Test.zip,
> image-2020-02-13-11-41-03-906.png
>
>
> We have been using maven-surefire-plugin in 2.22.1 and Junit4.13 for our
> testing. Now we are trying to upgrade junit to junit5 and saw that the
> r{color:#6a8759}erunFailingTestsCount parameter isn't working with surefire
> plugin version. I upgraded surefire to 3.0.0.M4 and verified that the failing
> tests are now being retried. But the issue is flaky tests show up in the
> report as Failures.
> {color}
>
> {color:#6a8759}ie. the log shows
> {color}
> [WARNING] Tests run: 10455, Failures: 0, Errors: 0, Skipped: 993, Flakes: 10
>
> But the actual surefire report shows like below
> !image-2020-02-13-11-41-03-906.png!
>
> This is blocking our junit5 upgrade task. Can you please provide a fix for
> this at the earliest? Please let me know if you need anything else from me to
> help with the investigation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SUREFIRE-1751) Surefire report shows flaky tests as failures
[
https://issues.apache.org/jira/browse/SUREFIRE-1751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anu updated SUREFIRE-1751:
--
Attachment: TEST-com.test.Flakes.xml
> Surefire report shows flaky tests as failures
> -
>
> Key: SUREFIRE-1751
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1751
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.0.0-M4
>Reporter: Anu
>Priority: Critical
> Attachments: TEST-com.test.Flakes.xml, Test.zip,
> image-2020-02-13-11-41-03-906.png
>
>
> We have been using maven-surefire-plugin in 2.22.1 and Junit4.13 for our
> testing. Now we are trying to upgrade junit to junit5 and saw that the
> r{color:#6a8759}erunFailingTestsCount parameter isn't working with surefire
> plugin version. I upgraded surefire to 3.0.0.M4 and verified that the failing
> tests are now being retried. But the issue is flaky tests show up in the
> report as Failures.
> {color}
>
> {color:#6a8759}ie. the log shows
> {color}
> [WARNING] Tests run: 10455, Failures: 0, Errors: 0, Skipped: 993, Flakes: 10
>
> But the actual surefire report shows like below
> !image-2020-02-13-11-41-03-906.png!
>
> This is blocking our junit5 upgrade task. Can you please provide a fix for
> this at the earliest? Please let me know if you need anything else from me to
> help with the investigation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (SUREFIRE-1134) Take list of tests from file (-Dtest has upper limits for comma-separated list of tests)
[
https://issues.apache.org/jira/browse/SUREFIRE-1134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17038580#comment-17038580
]
Daniel Elsner edited comment on SUREFIRE-1134 at 2/17/20 7:14 PM:
--
@Tibor You are right, it is possible to select specific *test classes* with
`-Dsurefire.includesFile` etc., but it is not possible to select specific *test
cases*, e.g., test methods with `@Test` annotation in JUnit. This is a
limitation, as one might only want to include specific test cases rather than
entire test classes.
It is implemented here:
[https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java#L2092]
Of course, you can still use `-Dtest` to specify methods, but this has its
restrictions, as for example in Windows environments, you cannot have more than
8192 characters in a single command (e.g. powershell/cmd.exe). Hence, selecting
a few hundred tests with long package names will fail.
Maybe we could either remove the check for method names in
`-Dsurefire.includesFile` or add `-DtestListFile=testsToRun.txt` as @Paul
suggested above.
was (Author: delsner):
@Tibor You are right, it is possible to select specific *test classes* with
`-Dsurefire.includesFile` etc., but it is not possible to select specific *test
cases*, e.g., test methods with `@Test` annotation in JUnit. This is a
limitation, as one might only want to include specific test cases rather than
entire test classes.
It is implemented here:
https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java#L2092
Of course, you can still use `-Dtest` to specify methods, but this has its
restrictions, as for example in Windows environments, you cannot have more than
8192 characters in a single command (e.g. powershell/cmd.exe). Hence, selecting
a few hundred tests with long package names will fail.
Maybe we could either remove the check for method names in
`Dsurefire.includesFile` or add `-DtestListFile=testsToRun.txt` as @Paul
suggested above.
> Take list of tests from file (-Dtest has upper limits for comma-separated
> list of tests)
>
>
> Key: SUREFIRE-1134
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1134
> Project: Maven Surefire
> Issue Type: New Feature
>Reporter: Paul Hammant
>Assignee: Tibor Digana
>Priority: Minor
> Fix For: 2.19
>
>
> -Dtest=TestOne,foo.BarTest is the way to go for constraining surefire to a
> list of tests. There are upper limits to that in the context of command line
> arguments.
> Could we additionally have:
> {panel:title=Example mvn
> param|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#CE}
> -DtestListFile=testsToRun.txt
> {panel}
> Also for Failsafe:
> {panel:title=Example mvn
> param|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#CE}
> -Dit.testListFile=testsToRun.txt
> {panel}
> Yes, I'd be rewriting testsToRun.txt for my use case, just before invoking
> Maven.
> Refer
> http://paulhammant.com/2015/01/11/reducing-test-times-by-only-running-impacted-tests/
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1134) Take list of tests from file (-Dtest has upper limits for comma-separated list of tests)
[
https://issues.apache.org/jira/browse/SUREFIRE-1134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17038580#comment-17038580
]
Daniel Elsner commented on SUREFIRE-1134:
-
@Tibor You are right, it is possible to select specific *test classes* with
`-Dsurefire.includesFile` etc., but it is not possible to select specific *test
cases*, e.g., test methods with `@Test` annotation in JUnit. This is a
limitation, as one might only want to include specific test cases rather than
entire test classes.
It is implemented here:
https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java#L2092
Of course, you can still use `-Dtest` to specify methods, but this has its
restrictions, as for example in Windows environments, you cannot have more than
8192 characters in a single command (e.g. powershell/cmd.exe). Hence, selecting
a few hundred tests with long package names will fail.
Maybe we could either remove the check for method names in
`Dsurefire.includesFile` or add `-DtestListFile=testsToRun.txt` as @Paul
suggested above.
> Take list of tests from file (-Dtest has upper limits for comma-separated
> list of tests)
>
>
> Key: SUREFIRE-1134
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1134
> Project: Maven Surefire
> Issue Type: New Feature
>Reporter: Paul Hammant
>Assignee: Tibor Digana
>Priority: Minor
> Fix For: 2.19
>
>
> -Dtest=TestOne,foo.BarTest is the way to go for constraining surefire to a
> list of tests. There are upper limits to that in the context of command line
> arguments.
> Could we additionally have:
> {panel:title=Example mvn
> param|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#CE}
> -DtestListFile=testsToRun.txt
> {panel}
> Also for Failsafe:
> {panel:title=Example mvn
> param|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#CE}
> -Dit.testListFile=testsToRun.txt
> {panel}
> Yes, I'd be rewriting testsToRun.txt for my use case, just before invoking
> Maven.
> Refer
> http://paulhammant.com/2015/01/11/reducing-test-times-by-only-running-impacted-tests/
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MJAVADOC-639) aggregate should use all requires static from maven modules
[ https://issues.apache.org/jira/browse/MJAVADOC-639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MJAVADOC-639: Attachment: MJAVADOC-639_aggr_static_modulepath.zip > aggregate should use all requires static from maven modules > --- > > Key: MJAVADOC-639 > URL: https://issues.apache.org/jira/browse/MJAVADOC-639 > Project: Maven Javadoc Plugin > Issue Type: Bug > Components: javadoc >Reporter: Olivier Lamy >Assignee: Olivier Lamy >Priority: Major > Fix For: 3.2.0 > > Attachments: MJAVADOC-639_aggr_static_modulepath.zip > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven] rfscholte commented on a change in pull request #329: Mng 5760 resume from without args
rfscholte commented on a change in pull request #329: Mng 5760 resume from without args URL: https://github.com/apache/maven/pull/329#discussion_r380322605 ## File path: maven-embedder/src/main/java/org/apache/maven/cli/CLIManager.java ## @@ -134,7 +134,7 @@ public CLIManager() options.addOption( Option.builder( FAIL_FAST ).longOpt( "fail-fast" ).desc( "Stop at first failure in reactorized builds" ).build() ); options.addOption( Option.builder( FAIL_AT_END ).longOpt( "fail-at-end" ).desc( "Only fail the build afterwards; allow all non-impacted builds to continue" ).build() ); options.addOption( Option.builder( FAIL_NEVER ).longOpt( "fail-never" ).desc( "NEVER fail the build, regardless of project result" ).build() ); -options.addOption( Option.builder( RESUME_FROM ).longOpt( "resume-from" ).hasArg().desc( "Resume reactor from specified project" ).build() ); +options.addOption( Option.builder( RESUME_FROM ).longOpt( "resume-from" ).hasArg().optionalArg( true ).desc( "Resume reactor from last failed project or specified project" ).build() ); Review comment: Module might cause more confusion due to JPMS. However it is a Maven MultiModule project... sorry, didn't answer your question ;) This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven] rfscholte commented on a change in pull request #329: Mng 5760 resume from without args
rfscholte commented on a change in pull request #329: Mng 5760 resume from
without args
URL: https://github.com/apache/maven/pull/329#discussion_r380321406
##
File path: maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java
##
@@ -1079,6 +1084,33 @@ private String getResumeFrom( List
mavenProjects, MavenProject fai
return ":" + failedProject.getArtifactId();
}
+private boolean createResumeFromCacheFile( MavenExecutionResult result,
String resumeFromProject )
+{
+String buildDirectory = result.getProject().getBuild().getDirectory();
+File buildDirectoryFile = new File( buildDirectory );
+boolean isBuildDirectoryPresent = ( buildDirectoryFile.exists() ||
buildDirectoryFile.mkdirs() );
+if ( isBuildDirectoryPresent )
+{
+Path resumeFromCache = Paths.get( buildDirectory,
"resume-from-cache" );
+try
+{
+Files.write( resumeFromCache, resumeFromProject.getBytes() );
Review comment:
Will work for now, but the MavenExecutionRequest might contain more
information worth storing
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[jira] [Commented] (MINVOKER-258) file line endings encoding
[ https://issues.apache.org/jira/browse/MINVOKER-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17038546#comment-17038546 ] Robert Scholte commented on MINVOKER-258: - Git clone should fix that, so it'll be OS specific. > file line endings encoding > -- > > Key: MINVOKER-258 > URL: https://issues.apache.org/jira/browse/MINVOKER-258 > Project: Maven Invoker Plugin > Issue Type: Task >Reporter: Slawomir Jaranowski >Priority: Major > > In project some files have CRLF and some other LF. > What kind should be? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (MINVOKER-258) file line endings encoding
Slawomir Jaranowski created MINVOKER-258: Summary: file line endings encoding Key: MINVOKER-258 URL: https://issues.apache.org/jira/browse/MINVOKER-258 Project: Maven Invoker Plugin Issue Type: Task Reporter: Slawomir Jaranowski In project some files have CRLF and some other LF. What kind should be? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1752) Implement new value for the "parallel" config element (e.g. "categories")
[
https://issues.apache.org/jira/browse/SUREFIRE-1752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17038535#comment-17038535
]
Stephan Bauer commented on SUREFIRE-1752:
-
Many thanks for the fast reply!
In order to keep it simple, I could live with a basic solution that only
considers the annotation at the class level. We have a strict 1:1 relation
between Testclass and Category. So other users who currently have test methods
for different Categories in one Testclass could still refactor the testclass
and divide it by Category if they need the parallel feature.
This also means that we do not use the inheritance feature for categories. Thus
we could also live with the restriction that only the annotated category of the
testclass itself gets considered. But I suppose you have to decide if you want
to provide such a very basic solution.
> Implement new value for the "parallel" config element (e.g. "categories")
> -
>
> Key: SUREFIRE-1752
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1752
> Project: Maven Surefire
> Issue Type: New Feature
> Components: Junit 4.7+ (parallel) support
>Affects Versions: 3.0.0-M4
>Reporter: Stephan Bauer
>Priority: Major
>
> According to
> [http://maven.apache.org/surefire/maven-failsafe-plugin/integration-test-mojo.html]
> the "parallel" configuration element currently only supports the following
> values:
> * suites
> * suitesAndClasses
> * suitesAndMethods
> * classesAndMethods
> We have a huge multi-module application with integrationtests living in many
> separate integrationtest-modules. Until now, all the integrationtests were
> executed through one additional central integrationtest-module, that
> contained the testsuite definitions. Each testsuites consists of tests from
> different integrationtest-modules.
> Example:
> * Testsuite A refers to tests from integrationtest-modules M1, M2 and M3
> * Testsuite B refers to tests from integrationtest-modules M1, M3 and M4
> * Testsuite C refers to tests from integrationtest-modules M2, M3 and M4
> (all testsuites are disjoint, which means that each test belongs to exactly
> one testsuite)
> Until now, the different testsuites were configured to be run in parallel, by
> using:
> {code:java}
>
> org.apache.maven.plugins
> maven-failsafe-plugin
> 3.0.0-M3
>
> suites
> 5
>
>
> {code}
> The central integrationtest module occurs to be more or less a hack, because
> you need to duplicate all dependencies from all integrationtest modules. This
> results in the fact, that any integrationtest is not executed with the
> classpath of its own module but of the central module.
> This turns out to be problematic sometimes (PS: furthermore we couldn't
> manage to configure the jacoco-maven-plugin properly so that the coverage of
> all the integrationtests could not measured correcty).
> The idea to solve this is to replace the Testsuites with the Junit4
> Categories. Unfortunately, the failsafe-plugin does not provide a value for
> the "parallel" config element based on the Junit categories. The consequence
> is, that all integrationtests now run serially which takes far too long and
> thus is not acceptable for us.
> PS: Another alternative solution would be to upgrade to Junit5 and have
> parallelization based on the new "Tag" element. But obviously there is no
> such support available either.
> PS-2: sorry for possibly using the wrong priority. Of course this is rather
> important for us, because it keeps us from moving away from the old central
> integrationtest module which is very annoying. I'm wondering that nobody else
> seems to have the same requirement as I can't imagine, that our usecase with
> testsuites spanning tests from different integrationtest modules is so
> exotic...
> Best regards,
> Stephan
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1752) Implement new value for the "parallel" config element (e.g. "categories")
[
https://issues.apache.org/jira/browse/SUREFIRE-1752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17038526#comment-17038526
]
Tibor Digana commented on SUREFIRE-1752:
Essentially you want to make the annotation @Category parallel?
The logic behind this annotation is complex because there is also the
inheritance of annotations, and there has to be considered the annottaion on
the method too.
How would you like to have it working?
> Implement new value for the "parallel" config element (e.g. "categories")
> -
>
> Key: SUREFIRE-1752
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1752
> Project: Maven Surefire
> Issue Type: New Feature
> Components: Junit 4.7+ (parallel) support
>Affects Versions: 3.0.0-M4
>Reporter: Stephan Bauer
>Priority: Major
>
> According to
> [http://maven.apache.org/surefire/maven-failsafe-plugin/integration-test-mojo.html]
> the "parallel" configuration element currently only supports the following
> values:
> * suites
> * suitesAndClasses
> * suitesAndMethods
> * classesAndMethods
> We have a huge multi-module application with integrationtests living in many
> separate integrationtest-modules. Until now, all the integrationtests were
> executed through one additional central integrationtest-module, that
> contained the testsuite definitions. Each testsuites consists of tests from
> different integrationtest-modules.
> Example:
> * Testsuite A refers to tests from integrationtest-modules M1, M2 and M3
> * Testsuite B refers to tests from integrationtest-modules M1, M3 and M4
> * Testsuite C refers to tests from integrationtest-modules M2, M3 and M4
> (all testsuites are disjoint, which means that each test belongs to exactly
> one testsuite)
> Until now, the different testsuites were configured to be run in parallel, by
> using:
> {code:java}
>
> org.apache.maven.plugins
> maven-failsafe-plugin
> 3.0.0-M3
>
> suites
> 5
>
>
> {code}
> The central integrationtest module occurs to be more or less a hack, because
> you need to duplicate all dependencies from all integrationtest modules. This
> results in the fact, that any integrationtest is not executed with the
> classpath of its own module but of the central module.
> This turns out to be problematic sometimes (PS: furthermore we couldn't
> manage to configure the jacoco-maven-plugin properly so that the coverage of
> all the integrationtests could not measured correcty).
> The idea to solve this is to replace the Testsuites with the Junit4
> Categories. Unfortunately, the failsafe-plugin does not provide a value for
> the "parallel" config element based on the Junit categories. The consequence
> is, that all integrationtests now run serially which takes far too long and
> thus is not acceptable for us.
> PS: Another alternative solution would be to upgrade to Junit5 and have
> parallelization based on the new "Tag" element. But obviously there is no
> such support available either.
> PS-2: sorry for possibly using the wrong priority. Of course this is rather
> important for us, because it keeps us from moving away from the old central
> integrationtest module which is very annoying. I'm wondering that nobody else
> seems to have the same requirement as I can't imagine, that our usecase with
> testsuites spanning tests from different integrationtest modules is so
> exotic...
> Best regards,
> Stephan
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (SUREFIRE-1752) Implement new value for the "parallel" config element (e.g. "categories")
Stephan Bauer created SUREFIRE-1752:
---
Summary: Implement new value for the "parallel" config element
(e.g. "categories")
Key: SUREFIRE-1752
URL: https://issues.apache.org/jira/browse/SUREFIRE-1752
Project: Maven Surefire
Issue Type: New Feature
Components: Junit 4.7+ (parallel) support
Affects Versions: 3.0.0-M4
Reporter: Stephan Bauer
According to
[http://maven.apache.org/surefire/maven-failsafe-plugin/integration-test-mojo.html]
the "parallel" configuration element currently only supports the following
values:
* suites
* suitesAndClasses
* suitesAndMethods
* classesAndMethods
We have a huge multi-module application with integrationtests living in many
separate integrationtest-modules. Until now, all the integrationtests were
executed through one additional central integrationtest-module, that contained
the testsuite definitions. Each testsuites consists of tests from different
integrationtest-modules.
Example:
* Testsuite A refers to tests from integrationtest-modules M1, M2 and M3
* Testsuite B refers to tests from integrationtest-modules M1, M3 and M4
* Testsuite C refers to tests from integrationtest-modules M2, M3 and M4
(all testsuites are disjoint, which means that each test belongs to exactly one
testsuite)
Until now, the different testsuites were configured to be run in parallel, by
using:
{code:java}
org.apache.maven.plugins
maven-failsafe-plugin
3.0.0-M3
suites
5
{code}
The central integrationtest module occurs to be more or less a hack, because
you need to duplicate all dependencies from all integrationtest modules. This
results in the fact, that any integrationtest is not executed with the
classpath of its own module but of the central module.
This turns out to be problematic sometimes (PS: furthermore we couldn't manage
to configure the jacoco-maven-plugin properly so that the coverage of all the
integrationtests could not measured correcty).
The idea to solve this is to replace the Testsuites with the Junit4 Categories.
Unfortunately, the failsafe-plugin does not provide a value for the "parallel"
config element based on the Junit categories. The consequence is, that all
integrationtests now run serially which takes far too long and thus is not
acceptable for us.
PS: Another alternative solution would be to upgrade to Junit5 and have
parallelization based on the new "Tag" element. But obviously there is no such
support available either.
PS-2: sorry for possibly using the wrong priority. Of course this is rather
important for us, because it keeps us from moving away from the old central
integrationtest module which is very annoying. I'm wondering that nobody else
seems to have the same requirement as I can't imagine, that our usecase with
testsuites spanning tests from different integrationtest modules is so exotic...
Best regards,
Stephan
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-surefire] Tibor17 commented on issue #240: [SUREFIRE-1658] TCP/IP Channel for forked Surefire JVM. Extensions API and SPI. Polymorphism for remote and local process communication.
Tibor17 commented on issue #240: [SUREFIRE-1658] TCP/IP Channel for forked Surefire JVM. Extensions API and SPI. Polymorphism for remote and local process communication. URL: https://github.com/apache/maven-surefire/pull/240#issuecomment-586975443 @eolivelli @jon-bell @rmannibucau I had to trigger the build for `85602d5` three times due to our build was downloading SNAPSHOT surefire jars from Apache repo. These are not compatible and should be avoided. My proposal is to add a new goal `-nsu` in the call of Verifier in the module `surefire-its`. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Created] (MNG-6867) extract methods, apply SLA DefaultMavenPluginManager
Arne Lewinski created MNG-6867: -- Summary: extract methods, apply SLA DefaultMavenPluginManager Key: MNG-6867 URL: https://issues.apache.org/jira/browse/MNG-6867 Project: Maven Issue Type: Improvement Components: core Reporter: Arne Lewinski Apply "extract method" refactoring to make methods smaller. Considering principle "single level of abstraction". -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MJAVADOC-639) aggregate should use all requires static from maven modules
[ https://issues.apache.org/jira/browse/MJAVADOC-639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated MJAVADOC-639: -- Summary: aggregate should use all requires static from maven modules (was: aggregate should use all require static from maven modules) > aggregate should use all requires static from maven modules > --- > > Key: MJAVADOC-639 > URL: https://issues.apache.org/jira/browse/MJAVADOC-639 > Project: Maven Javadoc Plugin > Issue Type: Bug > Components: javadoc >Reporter: Olivier Lamy >Assignee: Olivier Lamy >Priority: Major > Fix For: 3.2.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (MJAVADOC-639) aggregate should use all require static from maven modules
Olivier Lamy created MJAVADOC-639: - Summary: aggregate should use all require static from maven modules Key: MJAVADOC-639 URL: https://issues.apache.org/jira/browse/MJAVADOC-639 Project: Maven Javadoc Plugin Issue Type: Bug Components: javadoc Reporter: Olivier Lamy Assignee: Olivier Lamy -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MJAVADOC-639) aggregate should use all require static from maven modules
[ https://issues.apache.org/jira/browse/MJAVADOC-639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated MJAVADOC-639: -- Fix Version/s: 3.2.0 > aggregate should use all require static from maven modules > -- > > Key: MJAVADOC-639 > URL: https://issues.apache.org/jira/browse/MJAVADOC-639 > Project: Maven Javadoc Plugin > Issue Type: Bug > Components: javadoc >Reporter: Olivier Lamy >Assignee: Olivier Lamy >Priority: Major > Fix For: 3.2.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven] mthmulders commented on issue #329: Mng 5760 resume from without args
mthmulders commented on issue #329: Mng 5760 resume from without args URL: https://github.com/apache/maven/pull/329#issuecomment-586899735 I'm impressed by how you implemented this feature, @MartinKanters. Nice work! As for the file name, you might be able to introduce a constant for it. I'm all for failing "hard" when a user does `-rf` without a selector. It's an invalid use of the switch. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven] mthmulders commented on a change in pull request #329: Mng 5760 resume from without args
mthmulders commented on a change in pull request #329: Mng 5760 resume from
without args
URL: https://github.com/apache/maven/pull/329#discussion_r380068389
##
File path: maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java
##
@@ -1079,6 +1084,33 @@ private String getResumeFrom( List
mavenProjects, MavenProject fai
return ":" + failedProject.getArtifactId();
}
+private boolean createResumeFromCacheFile( MavenExecutionResult result,
String resumeFromProject )
+{
+String buildDirectory = result.getProject().getBuild().getDirectory();
+File buildDirectoryFile = new File( buildDirectory );
+boolean isBuildDirectoryPresent = ( buildDirectoryFile.exists() ||
buildDirectoryFile.mkdirs() );
Review comment:
Nitpicking: no brackets needed.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] [maven] mthmulders commented on a change in pull request #329: Mng 5760 resume from without args
mthmulders commented on a change in pull request #329: Mng 5760 resume from without args URL: https://github.com/apache/maven/pull/329#discussion_r380067529 ## File path: maven-embedder/src/main/java/org/apache/maven/cli/CLIManager.java ## @@ -134,7 +134,7 @@ public CLIManager() options.addOption( Option.builder( FAIL_FAST ).longOpt( "fail-fast" ).desc( "Stop at first failure in reactorized builds" ).build() ); options.addOption( Option.builder( FAIL_AT_END ).longOpt( "fail-at-end" ).desc( "Only fail the build afterwards; allow all non-impacted builds to continue" ).build() ); options.addOption( Option.builder( FAIL_NEVER ).longOpt( "fail-never" ).desc( "NEVER fail the build, regardless of project result" ).build() ); -options.addOption( Option.builder( RESUME_FROM ).longOpt( "resume-from" ).hasArg().desc( "Resume reactor from specified project" ).build() ); +options.addOption( Option.builder( RESUME_FROM ).longOpt( "resume-from" ).hasArg().optionalArg( true ).desc( "Resume reactor from last failed project or specified project" ).build() ); Review comment: @rfscholte, should the message read "last failed **project**" or "last failed **module**"? I still find myself struggling with terminology every now and then... This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven] mthmulders commented on a change in pull request #329: Mng 5760 resume from without args
mthmulders commented on a change in pull request #329: Mng 5760 resume from
without args
URL: https://github.com/apache/maven/pull/329#discussion_r380069017
##
File path: maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java
##
@@ -1079,6 +1084,33 @@ private String getResumeFrom( List
mavenProjects, MavenProject fai
return ":" + failedProject.getArtifactId();
}
+private boolean createResumeFromCacheFile( MavenExecutionResult result,
String resumeFromProject )
+{
+String buildDirectory = result.getProject().getBuild().getDirectory();
+File buildDirectoryFile = new File( buildDirectory );
+boolean isBuildDirectoryPresent = ( buildDirectoryFile.exists() ||
buildDirectoryFile.mkdirs() );
+if ( isBuildDirectoryPresent )
+{
+Path resumeFromCache = Paths.get( buildDirectory,
"resume-from-cache" );
+try
+{
+Files.write( resumeFromCache, resumeFromProject.getBytes() );
+return true;
+}
+catch ( IOException e )
+{
+slf4jLogger.debug( "Failed writing last failed project to
resume-from-cache file at: {}",
+resumeFromCache, e );
+return false;
+}
+}
+else
+{
+slf4jLogger.debug( "Failed creating build directory for root
project to store resume-from-cache file" );
Review comment:
Wouldn't it make sense to use a little more severe message? Most uses will
not see them, so they will not know they are missing out on this great new
feature :-)
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] [maven] mthmulders commented on a change in pull request #329: Mng 5760 resume from without args
mthmulders commented on a change in pull request #329: Mng 5760 resume from
without args
URL: https://github.com/apache/maven/pull/329#discussion_r380066969
##
File path:
maven-core/src/main/java/org/apache/maven/graph/DefaultGraphBuilder.java
##
@@ -282,15 +287,42 @@ else if ( StringUtils.isNotEmpty(
request.getMakeBehavior() ) )
{
List result = projects;
-if ( StringUtils.isNotEmpty( request.getResumeFrom() ) )
+if ( StringUtils.isNotEmpty( request.getResumeFrom() ) ||
request.isResumeFromLastFailedProject() )
{
File reactorDirectory = null;
if ( request.getBaseDirectory() != null )
{
reactorDirectory = new File( request.getBaseDirectory() );
}
-String selector = request.getResumeFrom();
+String selector;
+
+if ( StringUtils.isNotEmpty( request.getResumeFrom() ) )
+{
+selector = request.getResumeFrom();
+}
+else
+{
+String buildDirectory = projects.stream()
Review comment:
I would suggest to refactor this into a dedicated method, something like
`determineWhereToResumeBuild()`.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] [maven-invoker-plugin] slawekjaranowski commented on issue #13: [MINVOKER-257] Test code should meet checkstyle requirements
slawekjaranowski commented on issue #13: [MINVOKER-257] Test code should meet checkstyle requirements URL: https://github.com/apache/maven-invoker-plugin/pull/13#issuecomment-586863082 I prepared this PR, because last time @Tibor17 ask about checkstyle in test code. https://github.com/apache/maven-invoker-plugin/pull/7#issuecomment-549596895 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
