[GitHub] [maven-site] olamy merged pull request #194: [MNGSITE-426] update Jenkins URL
olamy merged pull request #194: URL: https://github.com/apache/maven-site/pull/194 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[GitHub] [maven-site] olamy commented on pull request #194: [MNGSITE-426] update Jenkins URL
olamy commented on pull request #194: URL: https://github.com/apache/maven-site/pull/194#issuecomment-674602039 @elharo we are adults NO NEED OF PR for such change 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[GitHub] [maven-site] elharo opened a new pull request #194: [MNGSITE-426] update Jenkins URL
elharo opened a new pull request #194: URL: https://github.com/apache/maven-site/pull/194 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Assumption fail treated as unexcepted exception?!
I see TestCopyMojo runs with JUnit38ClassRunner. Is it Assumptions[Assume since 4.4, AssumptionViolatedException since 4.12]-proof? Piotrek - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
AW: Assumption fail treated as unexcepted exception?!
Please see my answer to Martin Gainty, it proofs there is no NPE but
AssumptionViolatedException. It is a wrong assumption that all thrown
exceptions lead to test fail. It is JUnit's normal behavior that
Assume.assumeTrue(false) will throw AssumptionViolatedException, so that one
explicitly needs special treatment to skip the test, as this is the intention
of that JUnit API.
-Markus
-Ursprüngliche Nachricht-
Von: John Patrick [mailto:nhoj.patr...@gmail.com]
Gesendet: Sonntag, 16. August 2020 14:47
An: Maven Developers List
Betreff: Re: Assumption fail treated as unexcepted exception?!
If the code working out the assumption fails and causes a throwable,
either Runtime or Checked, I would expect the test to fail.
If you have a line something like below, and that causes a test error,
then that feels wrong as it's a valid assumption.
Assumptions.assumeFalse("ABC".equals("ABC"), "message");
But if you had below, which would throw an NPE, then that should error
as it's a badly coded assumption logic.
String IS_NULL = null;
Assumptions.assumeFalse(IS_NULL.equals("ABC"), "message");
So without seeing the test involved it's hard to tell if it's correct or not.
John
On Sun, 16 Aug 2020 at 13:31, Martin Gainty wrote:
>
> MG>below
>
>
> From: Markus KARG
> Sent: Sunday, August 16, 2020 7:40 AM
> To: dev@maven.apache.org
> Subject: Assumption fail treated as unexcepted exception?!
>
> Guys,
>
>
>
> I'm stuck with working on a new feature due to this, so I hope you can help
> me quickly:
>
>
>
> JUnit knows assumptions, assertions and exceptions. Failing assertions will
> FAIL tests (hence will fail maven builds). Failing assumptions will SKIP
> tests (hence will pass maven builds). Exceptions will ERROR tests (hence
> will break maven builds). Unfortunately today I noticed that assumptions
> actually ERROR test (hence fail builds) in Maven!
>
>
>
> (I simply added another test to maven dependency plugin which contains an
> always-failing assumption to proof the claim)
>
>
>
> [INFO] Results:
>
> [INFO]
>
> [ERROR] Errors:
>
> [ERROR] TestCopyMojo.proofClaim:274 ┐ AssumptionViolated always skip
>
> MG>get maven environment and debug information
> MG>mvn -e -X
> MG>also I know Junit 5.4.2 needs Hamcrest to be on classpath
> MG>can you tell us which version of Junit you are using?
>
> -Markus Karg
> ~gruss~
> ~martin~
>
>
>
>
>
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
AW: Assumption fail treated as unexcepted exception?!
The debug output is quite huge, so I won't put it here. What in particular
shall I lookup inside of that? The environment is:
Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555;
2019-04-04T21:00:29+02:00)
Maven home: C:\Program Files\apache-maven-3.6.1
Java version: 1.8.0_212, vendor: Azul Systems, Inc., runtime: C:\Program
Files\zulu8.38.0.13-ca-jdk8.0.212-win_x64\jre
Default locale: de_DE, platform encoding: Cp1252
OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "windows"
...
[DEBUG] Goal:
org.apache.maven.plugins:maven-surefire-plugin:2.22.0:test (default-test)
[DEBUG] Style: Regular
[DEBUG] Configuration:
${maven.test.additionalClasspath}
-Xmx384m
${childDelegation}
${maven.test.dependency.excludes}
${maven.surefire.debug}
${dependenciesToScan}
${disableXmlReport}
${enableAssertions}
${surefire.encoding}
true
${excludedGroups}
${surefire.excludesFile}
${surefire.failIfNoSpecifiedTests}
${failIfNoTests}
${forkCount}
${forkMode}
${surefire.exitTimeout}
${surefire.timeout}
${groups}
${surefire.includesFile}
${junitArtifactName}
${junitPlatformArti
factName}
${jvm}
${objectFactory}
${parallel}
${parallelOptimized}
${surefire.parallel.forcedTimeout}
${surefire.parallel.timeout}
${perCoreThreadCount}
${plugin.artifactMap}
${surefire.printSummary}
${project.artifactMap}
${maven.test.redirectTestOutputToFile}
${surefire.reportFormat}
${surefire.reportNameSuffix}
${surefire.rerunFailingTestsCount}
${reuseForks}
${surefire.runOrder}
${surefire.shutdown}
${maven.test.skip}
${surefire.skipAfterFailureCount}
${maven.test.skip.exec}
${skipTests}
${surefire.suiteXmlFiles}
C:\Program Files\apache-maven-3.6.1
${tempDir}
${test}
${maven.test.failure.ignore}
${testNGArtifactName}
${threadCount}
${threadCountClasses}
${threadCountMethods}
${threadCountSuites}
${trimStackTrace}
${surefire.useFile}
${surefire.useManifestOnlyJar}
${surefire.useSystemClassLoader}
${useUnlimitedThreads}
${basedir}
...
[ERROR]
testProofClaim(org.apache.maven.plugins.dependency.fromConfiguration.TestCop
yMojo) Time elapsed: 0.146 s <<< ERROR!
org.junit.AssumptionViolatedException: always skip
at
org.apache.maven.plugins.dependency.fromConfiguration.TestCopyMojo.testProof
Claim(TestCopyMojo.java:76)
...
IIUC, Maven debug doesn't contain any really specific information besides
what I aready assumed: Surefire treats org.junit.AssumptionViolatedException
as an error but not as a request to skip the test.
This can be reproduced with this really simple test case:
https://github.com/mkarg/maven-dependency-plugin/commit/af257d7987fc41ac4377
4d2dca60b201979d11a2 - as you can see, I just ask JUnit 4.13 to fail the
assumptions, and JUnit CORRECTLY throws AssumptionViolatedException - but
Maven seems to not specifically deal with it.
-Markus
-Ursprüngliche Nachricht-
Von: Martin Gainty [mailto:mgai...@hotmail.com]
Gesendet: Sonntag, 16. August 2020 14:24
An: Maven Developers List
Betreff: Re: Assumption fail treated as unexcepted exception?!
MG>below
From: Markus KARG
Sent: Sunday, August 16, 2020 7:40 AM
To: dev@maven.apache.org
Subject: Assumption fail treated as unexcepted exception?!
Guys,
I'm stuck with working on a new feature due to this, so I hope you can help
me quickly:
JUnit knows assumptions, assertions and exceptions. Failing assertions will
FAIL tests (hence will fail maven builds). Failing assumptions will SKIP
tests (hence will pass maven builds). Exceptions will ERROR tests (hence
will break maven builds). Unfortunately today I noticed that assumptions
actually ERROR test (hence fail builds) in Maven!
(I simply added another test to maven dependency plugin which contains an
always-failing assumption to proof the claim)
[INFO] Results:
[INFO]
[ERROR] Errors:
[ERROR] TestCopyMojo.proofClaim:274 ┐ AssumptionViolated always skip
MG>get maven environment and debug information
MG>mvn -e -X
MG>also I know Junit 5.4.2 needs Hamcrest to be on classpath
MG>can you tell us which version of Junit you are using?
-Markus Karg
~gruss~
~martin~
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: Assumption fail treated as unexcepted exception?!
If the code working out the assumption fails and causes a throwable,
either Runtime or Checked, I would expect the test to fail.
If you have a line something like below, and that causes a test error,
then that feels wrong as it's a valid assumption.
Assumptions.assumeFalse("ABC".equals("ABC"), "message");
But if you had below, which would throw an NPE, then that should error
as it's a badly coded assumption logic.
String IS_NULL = null;
Assumptions.assumeFalse(IS_NULL.equals("ABC"), "message");
So without seeing the test involved it's hard to tell if it's correct or not.
John
On Sun, 16 Aug 2020 at 13:31, Martin Gainty wrote:
>
> MG>below
>
>
> From: Markus KARG
> Sent: Sunday, August 16, 2020 7:40 AM
> To: dev@maven.apache.org
> Subject: Assumption fail treated as unexcepted exception?!
>
> Guys,
>
>
>
> I'm stuck with working on a new feature due to this, so I hope you can help
> me quickly:
>
>
>
> JUnit knows assumptions, assertions and exceptions. Failing assertions will
> FAIL tests (hence will fail maven builds). Failing assumptions will SKIP
> tests (hence will pass maven builds). Exceptions will ERROR tests (hence
> will break maven builds). Unfortunately today I noticed that assumptions
> actually ERROR test (hence fail builds) in Maven!
>
>
>
> (I simply added another test to maven dependency plugin which contains an
> always-failing assumption to proof the claim)
>
>
>
> [INFO] Results:
>
> [INFO]
>
> [ERROR] Errors:
>
> [ERROR] TestCopyMojo.proofClaim:274 ┐ AssumptionViolated always skip
>
> MG>get maven environment and debug information
> MG>mvn -e -X
> MG>also I know Junit 5.4.2 needs Hamcrest to be on classpath
> MG>can you tell us which version of Junit you are using?
>
> -Markus Karg
> ~gruss~
> ~martin~
>
>
>
>
>
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: Assumption fail treated as unexcepted exception?!
MG>below From: Markus KARG Sent: Sunday, August 16, 2020 7:40 AM To: dev@maven.apache.org Subject: Assumption fail treated as unexcepted exception?! Guys, I'm stuck with working on a new feature due to this, so I hope you can help me quickly: JUnit knows assumptions, assertions and exceptions. Failing assertions will FAIL tests (hence will fail maven builds). Failing assumptions will SKIP tests (hence will pass maven builds). Exceptions will ERROR tests (hence will break maven builds). Unfortunately today I noticed that assumptions actually ERROR test (hence fail builds) in Maven! (I simply added another test to maven dependency plugin which contains an always-failing assumption to proof the claim) [INFO] Results: [INFO] [ERROR] Errors: [ERROR] TestCopyMojo.proofClaim:274 ┐ AssumptionViolated always skip MG>get maven environment and debug information MG>mvn -e -X MG>also I know Junit 5.4.2 needs Hamcrest to be on classpath MG>can you tell us which version of Junit you are using? -Markus Karg ~gruss~ ~martin~
AW: Assumption fail treated as unexcepted exception?!
Happens with surefire 2.22.0 (but also with 3.0.0-M5, just tried it). Just added the assumption, did not otherwise touch any config properties, but maybe maven dependency plugin's existing build does that (haven't read the complete source). Any clue which property to search for which could produce that? Thanks -Markus -Ursprüngliche Nachricht- Von: Falko Modler [mailto:f.mod...@gmx.net] Gesendet: Sonntag, 16. August 2020 13:53 An: dev@maven.apache.org Betreff: Assumption fail treated as unexcepted exception?! Which surefire plugin version? Have you set any config properties? Cheers, Falko - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Assumption fail treated as unexcepted exception?!
Which surefire plugin version? Have you set any config properties? Cheers, Falko - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Assumption fail treated as unexcepted exception?!
Guys, I'm stuck with working on a new feature due to this, so I hope you can help me quickly: JUnit knows assumptions, assertions and exceptions. Failing assertions will FAIL tests (hence will fail maven builds). Failing assumptions will SKIP tests (hence will pass maven builds). Exceptions will ERROR tests (hence will break maven builds). Unfortunately today I noticed that assumptions actually ERROR test (hence fail builds) in Maven! (I simply added another test to maven dependency plugin which contains an always-failing assumption to proof the claim) [INFO] Results: [INFO] [ERROR] Errors: [ERROR] TestCopyMojo.proofClaim:274 ┐ AssumptionViolated always skip [INFO] [ERROR] Tests run: 257, Failures: 0, Errors: 1, Skipped: 0 It seems maven treats JUnit assumptions just like JUnit exceptions! :-( Can someone tell my why that happens? Do I have to set some option tell Maven it shall SKIP instead of ERROR on failing assumptions?! Thanks in advance! -Markus Karg
Re: Why is old IO API used in maven resolver?
Am 2020-08-16 um 06:40 schrieb STEFAN REICH: Hi there! I am working on a very large code base, and build performance issues made me look at the maven-resolver source code. In terms of File usages, there are a lot of InputStreams being copied around using ByteBuffer, instead of using FileChannel.transferTo. Affected classes are DefaultFileProcessor, ChecksumCalculator, WagonTransporter, AbstractTransporter and potentially more. Was it a conscious decision to use this pattern over the more efficient transferTo? Would you accept a PR with more modern NIO API that still works with JDK 7? Hi Stefan, I have been working on Resolver for the last couple of releases. Also on Wagon -- which goes hand in hand with Resolver. I don't think that there was a decision to go a suboptimal route. No one just stood up to make it better. Please start with Wagon first, because Resolver sits on top of Wagon which is low level. Here are the throughput results from a JMH benchmark, copying a 22MB file around using the pattern currently used in maven, and transferTo, as measured on macOS with JDK 11 on an SSD. Result "MyBenchmark.resolverCopy": 291.362 ±(99.9%) 5.443 ops/s [Average] (min, avg, max) = (276.923, 291.362, 302.911), stdev = 7.266 CI (99.9%): [285.919, 296.804] (assumes normal distribution) Result "MyBenchmark.transferTo": 325.188 ±(99.9%) 8.838 ops/s [Average] (min, avg, max) = (306.978, 325.188, 355.784), stdev = 11.799 CI (99.9%): [316.350, 334.026] (assumes normal distribution) Please provide your clean room tests, I have four different operating systems and JDKs to test. I will happily accept every PR which makes Resolver and Wagon better as long as the PRs are logically decoupled and wellreasoned. Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Why is old IO API used in maven resolver?
Hi. I wanna know how much it improve. could you please also run a corresponding jmh bencark for the old codes? Olivier Lamy 于 2020年8月16日周日 下午4:36写道： > On Sun, 16 Aug 2020 at 16:07, STEFAN REICH wrote: > > > Hi there! > > > > I am working on a very large code base, and build performance issues made > > me look at the maven-resolver source code. In terms of File usages, there > > are a lot of InputStreams being copied around using ByteBuffer, instead > of > > using FileChannel.transferTo. Affected classes are DefaultFileProcessor, > > ChecksumCalculator, WagonTransporter, AbstractTransporter and potentially > > more. Was it a conscious decision to use this pattern over the more > > efficient transferTo? Would you accept a PR with more modern NIO API that > > still works with JDK 7? > > > > yes please. > > > > Here are the throughput results from a JMH benchmark, copying a 22MB file > > around using the pattern currently used in maven, and transferTo, as > > measured on macOS with JDK 11 on an SSD. > > > > Result "MyBenchmark.resolverCopy": > > 291.362 ±(99.9%) 5.443 ops/s [Average] > > (min, avg, max) = (276.923, 291.362, 302.911), stdev = 7.266 > > CI (99.9%): [285.919, 296.804] (assumes normal distribution) > > > > Result "MyBenchmark.transferTo": > > 325.188 ±(99.9%) 8.838 ops/s [Average] > > (min, avg, max) = (306.978, 325.188, 355.784), stdev = 11.799 > > CI (99.9%): [316.350, 334.026] (assumes normal distribution) > > > > > sounds like a good result. > Will it be the same for all OS? (windows, linux. osx) > > > > > > > Thanks! > > Stefan > > > > -- > Olivier Lamy > http://twitter.com/olamy | http://linkedin.com/in/olamy >
Re: Why is old IO API used in maven resolver?
On Sun, 16 Aug 2020 at 16:07, STEFAN REICH wrote: > Hi there! > > I am working on a very large code base, and build performance issues made > me look at the maven-resolver source code. In terms of File usages, there > are a lot of InputStreams being copied around using ByteBuffer, instead of > using FileChannel.transferTo. Affected classes are DefaultFileProcessor, > ChecksumCalculator, WagonTransporter, AbstractTransporter and potentially > more. Was it a conscious decision to use this pattern over the more > efficient transferTo? Would you accept a PR with more modern NIO API that > still works with JDK 7? > yes please. > Here are the throughput results from a JMH benchmark, copying a 22MB file > around using the pattern currently used in maven, and transferTo, as > measured on macOS with JDK 11 on an SSD. > > Result "MyBenchmark.resolverCopy": > 291.362 ±(99.9%) 5.443 ops/s [Average] > (min, avg, max) = (276.923, 291.362, 302.911), stdev = 7.266 > CI (99.9%): [285.919, 296.804] (assumes normal distribution) > > Result "MyBenchmark.transferTo": > 325.188 ±(99.9%) 8.838 ops/s [Average] > (min, avg, max) = (306.978, 325.188, 355.784), stdev = 11.799 > CI (99.9%): [316.350, 334.026] (assumes normal distribution) > > sounds like a good result. Will it be the same for all OS? (windows, linux. osx) > > Thanks! > Stefan -- Olivier Lamy http://twitter.com/olamy | http://linkedin.com/in/olamy
Why is old IO API used in maven resolver?
Hi there! I am working on a very large code base, and build performance issues made me look at the maven-resolver source code. In terms of File usages, there are a lot of InputStreams being copied around using ByteBuffer, instead of using FileChannel.transferTo. Affected classes are DefaultFileProcessor, ChecksumCalculator, WagonTransporter, AbstractTransporter and potentially more. Was it a conscious decision to use this pattern over the more efficient transferTo? Would you accept a PR with more modern NIO API that still works with JDK 7? Here are the throughput results from a JMH benchmark, copying a 22MB file around using the pattern currently used in maven, and transferTo, as measured on macOS with JDK 11 on an SSD. Result "MyBenchmark.resolverCopy": 291.362 ±(99.9%) 5.443 ops/s [Average] (min, avg, max) = (276.923, 291.362, 302.911), stdev = 7.266 CI (99.9%): [285.919, 296.804] (assumes normal distribution) Result "MyBenchmark.transferTo": 325.188 ±(99.9%) 8.838 ops/s [Average] (min, avg, max) = (306.978, 325.188, 355.784), stdev = 11.799 CI (99.9%): [316.350, 334.026] (assumes normal distribution) Thanks! Stefan
