Jenkins build is back to normal : JMeter Windows #1648

[Apache Jenkins Server]

See 

Jenkins build is back to normal : JMeter-trunk #7691

[Apache Jenkins Server]

See 

Build failed in Jenkins: JMeter Windows #1647

[Apache Jenkins Server]

See 


Changes:

[pmouawad] Bug 64275 - Function Helper Dialog: Improve UX

[pmouawad] Bug 64276 - Search popup: Improve UX

[pmouawad] Bug 64277 - ForEach Controller: Improve UX


--
[...truncated 2.55 KB...]
 > git rev-parse "refs/remotes/origin/master^{commit}" # timeout=10
 > git rev-parse "refs/remotes/origin/origin/master^{commit}" # timeout=10
Checking out Revision 4c1e1e6c27f162913312129abfbb3e2a43281900 
(refs/remotes/origin/master)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 4c1e1e6c27f162913312129abfbb3e2a43281900
Commit message: "Bug 64277 - ForEach Controller: Improve UX"
 > git rev-list --no-walk 7a97d7f4df320c7f9afacf5babe6c01d4310f89b # timeout=10
[Gradle] - Launching build.
[JMeter Windows] $ cmd.exe /C 
'"" -PCI=true 
check assemble && exit %%ERRORLEVEL%%"
Downloading https://services.gradle.org/distributions/gradle-6.3-all.zip
.10%..20%..30%..40%..50%..60%.70%..80%..90%..100%

Welcome to Gradle 6.3!

Here are the highlights of this release:
 - Java 14 support
 - Improved error messages for unexpected failures

For more details see https://docs.gradle.org/6.3/release-notes.html

Starting a Gradle Daemon (subsequent builds will be faster)
> Task :buildSrc:compileKotlin NO-SOURCE
> Task :buildSrc:compileJava NO-SOURCE
> Task :buildSrc:compileGroovy NO-SOURCE
> Task :buildSrc:pluginDescriptors
> Task :buildSrc:processResources NO-SOURCE
> Task :buildSrc:classes UP-TO-DATE
> Task :buildSrc:inspectClassesForKotlinIC

> Task :buildSrc:jar
:jar: No valid plugin descriptors were found in META-INF/gradle-plugins

> Task :buildSrc:assemble
> Task :buildSrc:autostyleKotlinCheck NO-SOURCE
> Task :buildSrc:autostyleKotlinGradleCheck
> Task :buildSrc:autostyleCheck
> Task :buildSrc:compileTestKotlin NO-SOURCE
> Task :buildSrc:compileTestJava NO-SOURCE
> Task :buildSrc:compileTestGroovy NO-SOURCE
> Task :buildSrc:processTestResources NO-SOURCE
> Task :buildSrc:testClasses UP-TO-DATE
> Task :buildSrc:validatePlugins
> Task :buildSrc:batchtest:pluginDescriptors
> Task :buildSrc:batchtest:processResources
> Task :buildSrc:batchtest:autostyleKotlinCheck
> Task :buildSrc:batchtest:autostyleKotlinGradleCheck
> Task :buildSrc:batchtest:autostyleCheck
> Task :buildSrc:batchtest:processTestResources NO-SOURCE
> Task :buildSrc:batchtest:compileKotlin
> Task :buildSrc:batchtest:compileJava NO-SOURCE
> Task :buildSrc:batchtest:classes
> Task :buildSrc:batchtest:inspectClassesForKotlinIC
> Task :buildSrc:batchtest:jar
> Task :buildSrc:batchtest:assemble
> Task :buildSrc:batchtest:compileTestKotlin NO-SOURCE
> Task :buildSrc:batchtest:pluginUnderTestMetadata
> Task :buildSrc:pluginUnderTestMetadata
> Task :buildSrc:batchtest:compileTestJava NO-SOURCE
> Task :buildSrc:batchtest:testClasses UP-TO-DATE
> Task :buildSrc:test NO-SOURCE
> Task :buildSrc:check
> Task :buildSrc:build
> Task :buildSrc:batchtest:test NO-SOURCE
> Task :buildSrc:batchtest:validatePlugins
> Task :buildSrc:batchtest:check
> Task :buildSrc:batchtest:build
checksum-dependency elapsed time: 21498ms, configurations processed: 21
SHA-512 computation time: 1ms (goes in parallel, it might exceed wall-clock 
time), files processed: 1, processed: 0MiB, skipped: 334MiB
PGP signature resolution time: 12732ms (wall-clock), resolution requests: 
13, signatures resolved: 70
PGP key resolution time: 1903ms (wall-clock), resolution requests: 13, 
download time: 4923ms (goes in parallel, it might exceed wall-clock time), keys 
downloaded: 20
PGP signature verification time: 3344ms (goes in parallel, it might 
exceed wall-clock time), files processed: 70, processed: 119MiB, skipped: 215MiB

> Configure project :
Building JMeter 5.3-SNAPSHOT

> Configure project :src:dist-check
Certain tests will be skipped as they depend on external services and fail too 
often. Please add -PenableFlaky to enable them: [batchHttp4ImplDigestAuth, 
batchHttp4ImplPreemptiveBasicAuthJava, batchSlowCharsFeatureHttpClient4, 
batchSlowCharsFeatureJava, batchTCP_TESTS, batchTestKeepAlive, 
batchTestRedirectionPolicies]

> Task :src:bom:autostyleConfigsCheck NO-SOURCE
> Task :src:bshclient:autostyleConfigsCheck NO-SOURCE
> Task :src:core:versionClass
> Task :src:autostyleConfigsCheck
> Task :src:launcher:compileJava
> Task :src:launcher:processResources
> Task :src:launcher:classes
> Task :src:launcher:jar
> Task :autostyleConfigsCheck
> Task :src:testkit:compileJava
> Task :autostyleJavaCheck NO-SOURCE
> Task :src:components:autostyleConfigsCheck
> Task :src:components:autostyleGroovyCheck
> Task :src:testkit:processResources NO-SOURCE
> Task :src:testkit:classes
> Task :src:testkit:jar
> Task :src:testkit:compileTestFixturesJava NO-SOURCE
> 

Build failed in Jenkins: JMeter-trunk #7690

[Apache Jenkins Server]

See 


Changes:

[pmouawad] Bug 64277 - ForEach Controller: Improve UX


--
[...truncated 40.18 KB...]
> Task :autostyleJavaCheck NO-SOURCE
> Task :src:testkit-wiremock:autostyleJavaCheck
> Task :src:bshclient:autostyleJavaCheck
> Task :src:generator:autostyleJavaCheck
> Task :src:testkit:autostyleJavaCheck
> Task :src:protocol:bolt:autostyleJavaCheck
> Task :src:protocol:bolt:autostyleKotlinGradleCheck NO-SOURCE
> Task :src:launcher:autostyleJavaCheck
> Task :src:protocol:bolt:autostyleMarkdownCheck NO-SOURCE
> Task :src:protocol:bolt:autostyleCheck
> Task :src:protocol:jms:autostyleConfigsCheck NO-SOURCE
> Task :src:protocol:ftp:autostyleJavaCheck
> Task :src:protocol:ftp:autostyleKotlinGradleCheck NO-SOURCE
> Task :src:protocol:ftp:autostyleMarkdownCheck NO-SOURCE
> Task :src:protocol:ftp:autostyleCheck
> Task :src:protocol:junit:autostyleConfigsCheck NO-SOURCE
> Task :src:examples:autostyleJavaCheck
> Task :src:dist-check:autostyleJavaCheck
> Task :src:protocol:jdbc:autostyleJavaCheck
> Task :src:protocol:junit:autostyleJavaCheck
> Task :src:protocol:jdbc:autostyleKotlinGradleCheck NO-SOURCE
> Task :src:protocol:junit:autostyleKotlinGradleCheck NO-SOURCE
> Task :src:protocol:junit:autostyleMarkdownCheck NO-SOURCE
> Task :src:protocol:junit:autostyleCheck
> Task :src:protocol:jdbc:autostyleMarkdownCheck NO-SOURCE
> Task :src:protocol:jdbc:autostyleCheck
> Task :src:protocol:junit-sample:autostyleConfigsCheck NO-SOURCE
> Task :src:protocol:ldap:autostyleConfigsCheck NO-SOURCE
> Task :src:protocol:java:autostyleJavaCheck
> Task :src:protocol:java:autostyleKotlinGradleCheck NO-SOURCE
> Task :src:protocol:java:autostyleMarkdownCheck NO-SOURCE
> Task :src:protocol:java:autostyleCheck
> Task :src:protocol:mail:autostyleConfigsCheck NO-SOURCE

> Task :src:jorphan:compileJava
:37:
 warning: FontDesignMetrics is internal proprietary API and may be removed in a 
future release
import sun.font.FontDesignMetrics;
   ^

> Task :src:protocol:junit-sample:autostyleJavaCheck
> Task :src:protocol:junit-sample:autostyleKotlinGradleCheck NO-SOURCE
> Task :src:protocol:junit-sample:autostyleMarkdownCheck NO-SOURCE
> Task :src:protocol:junit-sample:autostyleCheck
> Task :src:protocol:junit-sample:processTestResources NO-SOURCE
> Task :src:protocol:mongodb:autostyleConfigsCheck
> Task :src:protocol:jms:autostyleJavaCheck
> Task :src:protocol:jms:autostyleKotlinGradleCheck NO-SOURCE
> Task :src:protocol:jms:autostyleMarkdownCheck NO-SOURCE
> Task :src:protocol:jms:autostyleCheck
> Task :src:protocol:native:autostyleConfigsCheck NO-SOURCE
> Task :src:protocol:native:autostyleJavaCheck
> Task :src:protocol:native:autostyleKotlinGradleCheck NO-SOURCE
> Task :src:protocol:native:autostyleMarkdownCheck NO-SOURCE
> Task :src:protocol:native:autostyleCheck
> Task :src:protocol:tcp:autostyleConfigsCheck NO-SOURCE
> Task :src:protocol:mongodb:autostyleJavaCheck
> Task :src:protocol:mongodb:autostyleKotlinGradleCheck NO-SOURCE
> Task :src:protocol:mongodb:autostyleMarkdownCheck NO-SOURCE
> Task :src:protocol:mongodb:autostyleCheck
> Task :src:protocol:mail:autostyleJavaCheck
> Task :src:protocol:mail:autostyleKotlinGradleCheck NO-SOURCE
> Task :src:protocol:mail:autostyleMarkdownCheck NO-SOURCE
> Task :src:protocol:mail:autostyleCheck
> Task :src:protocol:ldap:autostyleJavaCheck
> Task :src:protocol:ldap:autostyleKotlinGradleCheck NO-SOURCE
> Task :src:protocol:ldap:autostyleMarkdownCheck NO-SOURCE
> Task :src:protocol:ldap:autostyleCheck
> Task :src:protocol:tcp:autostyleJavaCheck
> Task :src:protocol:tcp:autostyleKotlinGradleCheck NO-SOURCE
> Task :src:protocol:tcp:autostyleMarkdownCheck NO-SOURCE
> Task :src:protocol:tcp:autostyleCheck
> Task :src:functions:autostyleJavaCheck

> Task :src:jorphan:compileJava
:172:
 warning: FontDesignMetrics is internal proprietary API and may be removed in a 
future release
return FontDesignMetrics.getMetrics(f).getHeight();
   ^
Note: 

 uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
2 warnings

> Task :src:jorphan:compileGroovy NO-SOURCE
> Task :src:jorphan:processResources UP-TO-DATE
> Task :src:jorphan:classes
> Task :src:jorphan:jar
> Task :src:jorphan:compileTestJava UP-TO-DATE
> Task :src:bshclient:autostyleKotlinGradleCheck
> Task :src:testkit:autostyleKotlinGradleCheck
> Task :src:generator:autostyleKotlinGradleCheck
> Task :src:testkit-wiremock:autostyleKotlinGradleCheck
> Task :src:examples:autostyleKotlinGradleCheck
> Task 

Re: Darklaf Intellij: when element is disabled its label is not readable Inbox x

[Vladimir Sitnikov]

Philippe>It's really nice, beautiful, clean , it's a big improvement for
JMeter
Philippe>design, thanks for your works Vladimir and Jannis.

Thanks!

Philippe>when you select it or
Philippe>the View Results Tree under it the selected element name is
unreadable.

In my experience, Darklaf has quite a number of demo classes, and it is
often possible to create an isolated example.
For example, I've filed this case as
https://github.com/weisJ/darklaf/issues/123

Even though Jannis is extremely fast at UI, you might try selecting colors
on your own.
If you clone JMeter and Darklaf repositories side by side, then you would
be able to launch JMeter as
./gradlew runGui -PlocalDarklaf
It would build Darklaf from sources, so you could make changes to Darklaf
and see how it works with JMeter.

Here's the list of colors: https://weisj.github.io/darklaf/

Vladimir

Darklaf Intellij: when element is disabled its label is not readable Inbox x

[Philippe Mouawad]

Hello,
I have started playing with last work on LAF and GUI.

It's really nice, beautiful, clean , it's a big improvement for JMeter
design, thanks for your works Vladimir and Jannis.

For now I just notice the following problem.
On Macosx, using Laf Darklaf/ IntelliJ, I used Recording Template.
It creates a disabled HTTP(S) Test Script Recorder, when you select it or
the View Results Tree under it the selected element name is unreadable.

Regards

Jenkins build is back to normal : JMeter Windows #1646

[Apache Jenkins Server]

See 

Build failed in Jenkins: JMeter Windows #1645

[Apache Jenkins Server]

See 


Changes:

[sitnikov.vladimir] Improve quality for "Save node as image" action

[sitnikov.vladimir] Bug 64142 - Avoid use of gray and disabled color for 
elements under


--
[...truncated 213.04 KB...]
Creating summariser 
Created the tree successfully using F:\jenkins\jenkins-slave\workspace\JMeter 
Windows\bin\testfiles\Bug56243.jmx
Mar 28, 2020 12:00:07 PM java.util.prefs.WindowsPreferences 
WARNING: Could not open/create prefs root node Software\JavaSoft\Prefs at root 
0x8002. Windows RegCreateKeyEx(...) returned error code 5.
Starting standalone test @ Sat Mar 28 12:00:07 PDT 2020 (1585422007700)
Waiting for possible Shutdown/StopTestNow/HeapDump/ThreadDump message on port 
4445
summary =  9 in 00:00:00 =   47.1/s Avg: 1 Min: 0 Max:14 Err:   
  0 (0.00%)
Tidying up ...@ Sat Mar 28 12:00:08 PDT 2020 (1585422008849)
... end of run
No errors present in the logfile F:\jenkins\jenkins-slave\workspace\JMeter 
Windows\bin\Bug56243.log (the file is empty)

> Task :src:protocol:http:test
  0.6sec,   55 completed,   0 failed,   0 skipped, 
org.apache.jmeter.curl.BasicCurlParserTest
  0.5sec,   21 completed,   0 failed,   0 skipped, 
org.apache.jmeter.gui.action.ParseCurlCommandActionTest
  0.1sec,3 completed,   0 failed,   0 skipped, 
org.apache.jmeter.protocol.http.config.MultipartUrlConfigTest
  0.0sec,2 completed,   0 failed,   0 skipped, 
org.apache.jmeter.protocol.http.config.UrlConfigTest
FAILURE   1.2sec, org.apache.jmeter.protocol.http.control.TestCacheManagerHC4 > 
testCacheHttpClientBug51932()
org.opentest4j.AssertionFailedError: Should not find valid entry ==> 
expected:  but was: 
at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55)
at org.junit.jupiter.api.AssertFalse.assertFalse(AssertFalse.java:40)
at org.junit.jupiter.api.Assertions.assertFalse(Assertions.java:218)
at 
org.apache.jmeter.protocol.http.control.TestCacheManagerBase.testCacheHttpClientBug51932(TestCacheManagerBase.java:365)
at 
org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:686)
at 
org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
at 
org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
at 
org.junit.jupiter.engine.extension.TimeoutInvocation.proceed(TimeoutInvocation.java:46)
at 
org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:149)
at 
org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:140)
at 
org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:84)
at 
org.junit.jupiter.engine.execution.ExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(ExecutableInvoker.java:115)
at 
org.junit.jupiter.engine.execution.ExecutableInvoker.lambda$invoke$0(ExecutableInvoker.java:105)
at 
org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
at 
org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
at 
org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
at 
org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
at 
org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:104)
at 
org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:98)
at 
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$6(TestMethodTestDescriptor.java:205)
at 
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at 
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:201)
at 
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:137)
at 
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:71)
at 
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$5(NodeTestTask.java:135)
at 
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at 
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$7(NodeTestTask.java:125)
at 
org.junit.platform.engine.support.hierarchical.Node.around(Node.java:135)
at 

Jenkins build is back to normal : JMeter-trunk #7684

[Apache Jenkins Server]

See 

Re: Screenshots: documentation, pull requests

[Vladimir Sitnikov]

>Is there somewhere we can host them, like netlify or S3, instead of git?

Well, we can try Netlify, however, I'm not sure we are OK within their
limits.
A year ago I've raised https://issues.apache.org/jira/browse/INFRA-18102 for
use of Netlify for documentation preview, and the infra response was not
that positive.

Now I see they enable GitHub-Netlify integration for some of the projects.

Do you think you could explore the ways to preview the results?

So far I see the following key outputs:
* Documentation (e.g. canned screenshots for use in the online
documentation)
* UI regression testing: the system should render new screenshots, compare
them (with tolerance) with the etalon ones
(e.g. with the current screenshots), and produce the list of the ones that
differ significantly.

>What about the custom highlights around specific parts of the screenshot

It would be nice to have as well as
* custom values for fields
* custom size for the control
* crop

Frankly speaking, I think behind the lines of Kotlin DSL for that.

>instead of git

We might want to have documentation for **all** JMeter versions on the
website at the same time.
In other words, it would be great to have a version selector, so the users
could check the documentation for their version.

That implies we might want to store screenshots for all the versions rather
than "the latest screenshot for ThreadGroupGui".

Vladimir

Build failed in Jenkins: JMeter-trunk #7683

[Apache Jenkins Server]

See 


Changes:

[sitnikov.vladimir] Update look and feel to tabbed panes as well


--
[...truncated 192.05 KB...]
  0.1sec,   10 completed,   0 failed,   0 skipped, 
org.apache.jmeter.assertions.ResponseAssertionTest
  0.0sec,   25 completed,   0 failed,   0 skipped, 
org.apache.jmeter.assertions.TestJSONPathAssertion
  0.4sec,7 completed,   0 failed,   0 skipped, 
org.apache.jmeter.assertions.jmespath.gui.JMESPathAssertionGuiTest
  0.0sec,4 completed,   0 failed,   0 skipped, 
org.apache.jmeter.assertions.DurationAssertionTest
  0.1sec,7 completed,   0 failed,   0 skipped, 
org.apache.jmeter.assertions.gui.TestJSONPathAssertionGui
  0.3sec,9 completed,   0 failed,   0 skipped, 
org.apache.jmeter.assertions.XMLSchemaAssertionTest
  0.3sec,   29 completed,   0 failed,   0 skipped, 
org.apache.jmeter.assertions.XPathAssertionTest
  0.1sec,3 completed,   0 failed,   0 skipped, 
org.apache.jmeter.visualizers.backend.SamplerMetricFixedModeTest
  2.1sec,4 completed,   0 failed,   0 skipped, 
org.apache.jmeter.visualizers.backend.influxdb.HttpMetricsSenderTest
  0.0sec,2 completed,   0 failed,   0 skipped, 
org.apache.jmeter.visualizers.backend.SamplerMetricTimedModeTest
  0.0sec,8 completed,   0 failed,   0 skipped, 
org.apache.jmeter.visualizers.TestRenderAsJson
  0.0sec,2 completed,   0 failed,   0 skipped, 
org.apache.jmeter.visualizers.TestSamplingStatCalculator
  0.0sec,5 completed,   0 failed,   0 skipped, 
org.apache.jmeter.reporters.TestResultSaver
  0.2sec,1 completed,   0 failed,   0 skipped, 
org.apache.jmeter.resources.ResourceKeyUsageTestComponents
  0.8sec,7 completed,   0 failed,   0 skipped, 
org.apache.jmeter.gui.action.template.TestTemplateManager
  0.0sec,1 completed,   0 failed,   0 skipped, 
org.apache.jmeter.gui.action.TestSave
WARNING   0.9sec,8 completed,   0 failed,   1 
skipped, org.apache.jmeter.control.TestIfController
  0.0sec,4 completed,   0 failed,   0 skipped, 
org.apache.jmeter.control.TestOnceOnlyController
  0.1sec,   12 completed,   0 failed,   0 skipped, 
org.apache.jmeter.control.TestWhileController
  0.0sec,4 completed,   0 failed,   0 skipped, 
org.apache.jmeter.control.TestLoopController
  0.0sec,1 completed,   0 failed,   0 skipped, 
org.apache.jmeter.control.TestTransactionController
  0.0sec,3 completed,   0 failed,   0 skipped, 
org.apache.jmeter.control.TestRandomController
  0.0sec,6 completed,   0 failed,   0 skipped, 
org.apache.jmeter.control.TestInterleaveControl
  0.0sec,1 completed,   0 failed,   0 skipped, 
org.apache.jmeter.control.TestGenericController
  0.2sec,   10 completed,   0 failed,   0 skipped, 
org.apache.jmeter.extractor.json.jmespath.TestJMESPathExtractor$SourceVarOrResponse
  0.0sec,   10 completed,   0 failed,   0 skipped, 
org.apache.jmeter.extractor.json.jmespath.TestJMESPathExtractor$MatchNumberMoreThanZeroOn1ExtractedValue
  0.0sec,6 completed,   0 failed,   0 skipped, 
org.apache.jmeter.extractor.json.jmespath.TestJMESPathExtractor$MultipleMatchesOnAllExtractedValues
  0.0sec,6 completed,   0 failed,   0 skipped, 
org.apache.jmeter.extractor.json.jmespath.TestJMESPathExtractor$OneMatchOnAllExtractedValues
  0.3sec,   32 completed,   0 failed,   0 skipped, 
org.apache.jmeter.extractor.json.jmespath.TestJMESPathExtractor
  0.0sec,   27 completed,   0 failed,   0 skipped, 
org.apache.jmeter.assertions.jmespath.TestJMESPathAssertion$TestAssertion
  0.0sec,   27 completed,   0 failed,   0 skipped, 
org.apache.jmeter.assertions.jmespath.TestJMESPathAssertion
  0.0sec,9 completed,   0 failed,   0 skipped, 
org.apache.jmeter.visualizers.TestSampleCompareTo
  0.9sec,8 completed,   0 failed,   0 skipped, 
org.apache.jmeter.extractor.json.render.RenderAsJsonRendererSpec
  0.1sec,8 completed,   0 failed,   0 skipped, 
org.apache.jmeter.extractor.json.render.RenderAsJmesPathRendererSpec
  0.0sec,4 completed,   0 failed,   0 skipped, 
org.apache.jmeter.extractor.JoddExtractorSpec
  0.2sec,   37 completed,   0 failed,   0 skipped, 
org.apache.jmeter.extractor.BoundaryExtractorSpec
  0.0sec,6 completed,   0 failed,   0 skipped, 
org.apache.jmeter.timers.UniformRandomTimerSpec
  0.1sec,7 completed,   0 failed,   0 skipped, 
org.apache.jmeter.assertions.CompareAssertionSpec
  0.0sec,7 completed,   0 failed,   0 skipped, 
org.apache.jmeter.assertions.MD5HexAssertionSpec
  0.2sec,5 completed,   0 failed,   0 skipped, 
org.apache.jmeter.assertions.gui.AssertionGuiSpec
  

Re: Screenshots: documentation, pull requests

[Graham Russell]

Great idea. There is a lot of room for improvement here.

Is there somewhere we can host them, like netlify or S3, instead of git?

What about the custom highlights around specific parts of the screenshot,
is that easy to automate too, but maybe not essential?

Graham

On Wed, 25 Mar 2020, 21:42 Vladimir Sitnikov, 
wrote:

> Hi,
>
> JMeter heavily relies on the UI, and would probably be nice if we could
> have machinery for automated screenshot generation.
>
> I see the following issues with the current screenshots:
> 1) They are often out of date
> 2) Image quality is not always good (e.g. LowDPI image does not work for
> HiDPI screen)
> 3) Image themes are not consistent. One screenshot can be dark, another can
> be light, and so on :(
>
> What do you think if we replace screenshots with automatically generated
> ones?


> I've created a draft PR: https://github.com/apache/jmeter/pull/574
> I implement a small class that instantiates GUI components and generates
> PNG files out of it.
>
> So far my findings are:
> a) The full set of screenshots takes ~7 megabytes (or ~3.5 after pngquant).
> We would probably want to keep screenshots in another repository.
> Otherwise, we could pollute the main source repository with images quite
> fast.
> b) Different operating systems have slightly different rendering because
> the default fonts are different
> c) If we use a different repository for storing screenshots, then we could
> render even multiple themes and add "preferred theme" switch to the website
> d) A single component might need more than one screenshot (e.g. HTTP
> request have multiple tabs)
>
>
> Any thoughts?
>
> Vladimir
>

Build failed in Jenkins: JMeter-trunk #7682

[Apache Jenkins Server]

See 


Changes:

[sitnikov.vladimir] Restore GuiPackage#nodesToGui as it is required for 
UnsharedComponent


--
[...truncated 184.03 KB...]

org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper#dispatch
 at line:182

org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper#dispatch
 at line:164
org.gradle.internal.remote.internal.hub.MessageHub$Handler#run at line:412

org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures#onExecute 
at line:64
org.gradle.internal.concurrent.ManagedExecutorImpl$1#run at line:48
java.util.concurrent.ThreadPoolExecutor#runWorker at line:1149
java.util.concurrent.ThreadPoolExecutor$Worker#run at line:624
org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable#run 
at line:56
java.lang.Thread#run at line:748

Thread[/127.0.0.1:33192 to /127.0.0.1:41375 workers Thread 2,5,main], 
stackTrace:sun.misc.Unsafe#park
java.util.concurrent.locks.LockSupport#park at line:175
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject#await 
at line:2039
org.gradle.internal.remote.internal.hub.queue.EndPointQueue#take at line:49
org.gradle.internal.remote.internal.hub.MessageHub$ConnectionDispatch#run 
at line:320

org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures#onExecute 
at line:64
org.gradle.internal.concurrent.ManagedExecutorImpl$1#run at line:48
java.util.concurrent.ThreadPoolExecutor#runWorker at line:1149
java.util.concurrent.ThreadPoolExecutor$Worker#run at line:624
org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable#run 
at line:56
java.lang.Thread#run at line:748

Thread[main,5,main], stackTrace:sun.misc.Unsafe#park
java.util.concurrent.locks.LockSupport#park at line:175
java.util.concurrent.locks.AbstractQueuedSynchronizer#parkAndCheckInterrupt 
at line:836

java.util.concurrent.locks.AbstractQueuedSynchronizer#doAcquireSharedInterruptibly
 at line:997

java.util.concurrent.locks.AbstractQueuedSynchronizer#acquireSharedInterruptibly
 at line:1304
java.util.concurrent.CountDownLatch#await at line:231
org.gradle.api.internal.tasks.testing.worker.TestWorker#execute at line:72
org.gradle.api.internal.tasks.testing.worker.TestWorker#execute at line:46
org.gradle.process.internal.worker.child.ActionExecutionWorker#execute at 
line:91
org.gradle.process.internal.worker.child.ActionExecutionWorker#execute at 
line:34

org.gradle.process.internal.worker.child.SystemApplicationClassLoaderWorker#call
 at line:137

org.gradle.process.internal.worker.child.SystemApplicationClassLoaderWorker#call
 at line:69
worker.org.gradle.process.internal.worker.GradleWorkerMain#run at line:68
worker.org.gradle.process.internal.worker.GradleWorkerMain#main at line:73

Thread[/127.0.0.1:33192 to /127.0.0.1:41375 workers Thread 3,5,main], 
stackTrace:sun.nio.ch.EPollArrayWrapper#epollWait
sun.nio.ch.EPollArrayWrapper#poll at line:269
sun.nio.ch.EPollSelectorImpl#doSelect at line:93
sun.nio.ch.SelectorImpl#lockAndDoSelect at line:86
sun.nio.ch.SelectorImpl#select at line:97
sun.nio.ch.SelectorImpl#select at line:101

org.gradle.internal.remote.internal.inet.SocketConnection$SocketInputStream#read
 at line:185
com.esotericsoftware.kryo.io.Input#fill at line:146
com.esotericsoftware.kryo.io.Input#require at line:178
com.esotericsoftware.kryo.io.Input#readByte at line:295
org.gradle.internal.serialize.kryo.KryoBackedDecoder#readByte at line:81

org.gradle.internal.remote.internal.hub.InterHubMessageSerializer$MessageReader#read
 at line:64

org.gradle.internal.remote.internal.hub.InterHubMessageSerializer$MessageReader#read
 at line:52
org.gradle.internal.remote.internal.inet.SocketConnection#receive at line:81
org.gradle.internal.remote.internal.hub.MessageHub$ConnectionReceive#run at 
line:268

org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures#onExecute 
at line:64
org.gradle.internal.concurrent.ManagedExecutorImpl$1#run at line:48
java.util.concurrent.ThreadPoolExecutor#runWorker at line:1149
java.util.concurrent.ThreadPoolExecutor$Worker#run at line:624
org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable#run 
at line:56
java.lang.Thread#run at line:748

  0.0sec,4 completed,   0 failed,   0 skipped, 
org.apache.jmeter.samplers.TestDataStrippingSampleSender

PackageTest > checkI18n fr: messages STANDARD_OUT
Ignoring missing junit_failure_default_code=0001 in 
org/apache/jmeter/resources/messages_fr.properties
Ignoring missing aggregate_report_90=90% in 
org/apache/jmeter/resources/messages_fr.properties
Ignoring missing junit_error_default_code= in 

Re: Groovy 2.4.18 vs Java 14

[Philippe Mouawad]

On Saturday, March 28, 2020, Felix Schumacher <
felix.schumac...@internetallee.de> wrote:

>
> Am 28.03.20 um 14:30 schrieb Vladimir Sitnikov:
> > Hi,
> >
> > AFAIK, the version of Groovy we use 2.4.18 does not support Java 14.
> >
> > Should we upgrade?
> > There are two options: 2.5.10 (see
> > http://groovy-lang.org/changelogs/changelog-2.5.10.html ) and 3.0.2 (
> > http://groovy-lang.org/changelogs/changelog-3.0.2.html )
> >
> > Does anybody have any preference?
> >
> > I think it might be ok to go with 3.0.2
>
> +1


Would also go for this one.
Is there a risk of breaking existing groovy scripts ?

https://groovy-lang.org/releasenotes/groovy-2.5.html#Groovy2.5releasenotes-Breakingchanges

https://groovy-lang.org/releasenotes/groovy-3.0.html#_other_breaking_changes



> Felix
>
> >
> > Vladimir
> >
>


-- 
Cordialement.
Philippe Mouawad.

Build failed in Jenkins: JMeter-trunk #7681

[Apache Jenkins Server]

See 


Changes:

[sitnikov.vladimir] Upgrade Gradle: 6.1 -> 6.3


--
[...truncated 184.35 KB...]
  0.0sec,6 completed,   0 failed,   0 skipped, 
org.apache.jmeter.control.TestInterleaveControl
WARNING   1.2sec,8 completed,   0 failed,   1 
skipped, org.apache.jmeter.control.TestIfController
  0.0sec,4 completed,   0 failed,   0 skipped, 
org.apache.jmeter.control.TestOnceOnlyController
  0.1sec,4 completed,   0 failed,   0 skipped, 
org.apache.jmeter.control.TestLoopController
  0.0sec,1 completed,   0 failed,   0 skipped, 
org.apache.jmeter.control.TestGenericController
  0.0sec,3 completed,   0 failed,   0 skipped, 
org.apache.jmeter.control.TestRandomController
  0.0sec,   12 completed,   0 failed,   0 skipped, 
org.apache.jmeter.control.TestWhileController
  0.0sec,1 completed,   0 failed,   0 skipped, 
org.apache.jmeter.control.TestTransactionController
  0.0sec,4 completed,   0 failed,   0 skipped, 
org.apache.jmeter.extractor.TestBoundaryExtractor
  0.2sec,   14 completed,   0 failed,   0 skipped, 
org.apache.jmeter.extractor.TestHtmlExtractorJodd
  0.1sec,   25 completed,   0 failed,   0 skipped, 
org.apache.jmeter.extractor.TestRegexExtractor
  0.8sec,7 completed,   0 failed,   0 skipped, 
org.apache.jmeter.extractor.TestXPath2Extractor
  0.3sec,6 completed,   0 failed,   0 skipped, 
org.apache.jmeter.extractor.TestXPathExtractor
  0.1sec,9 completed,   0 failed,   0 skipped, 
org.apache.jmeter.extractor.TestJSONPostProcessor
  0.2sec,   14 completed,   0 failed,   0 skipped, 
org.apache.jmeter.extractor.TestHtmlExtractorJSoup
  0.0sec,5 completed,   0 failed,   0 skipped, 
org.apache.jmeter.reporters.TestResultSaver
  0.1sec,   10 completed,   0 failed,   0 skipped, 
org.apache.jmeter.assertions.ResponseAssertionTest
  0.2sec,7 completed,   0 failed,   0 skipped, 
org.apache.jmeter.assertions.gui.TestJSONPathAssertionGui
  0.3sec,   29 completed,   0 failed,   0 skipped, 
org.apache.jmeter.assertions.XPathAssertionTest
  0.0sec,6 completed,   0 failed,   0 skipped, 
org.apache.jmeter.assertions.SizeAssertionTest
  0.0sec,4 completed,   0 failed,   0 skipped, 
org.apache.jmeter.assertions.DurationAssertionTest
  0.1sec,7 completed,   0 failed,   0 skipped, 
org.apache.jmeter.assertions.jmespath.gui.JMESPathAssertionGuiTest
  0.1sec,   14 completed,   0 failed,   0 skipped, 
org.apache.jmeter.assertions.XPath2AssertionTest
  0.9sec,6 completed,   0 failed,   0 skipped, 
org.apache.jmeter.assertions.SMIMEAssertionTest
  0.0sec,   25 completed,   0 failed,   0 skipped, 
org.apache.jmeter.assertions.TestJSONPathAssertion
  0.4sec,9 completed,   0 failed,   0 skipped, 
org.apache.jmeter.assertions.XMLSchemaAssertionTest
  0.0sec,4 completed,   0 failed,   0 skipped, 
org.apache.jmeter.assertions.XmlAssertionTest
  0.0sec,9 completed,   0 failed,   0 skipped, 
org.apache.jmeter.visualizers.TestSampleCompareTo
  0.3sec,   10 completed,   0 failed,   0 skipped, 
org.apache.jmeter.extractor.json.jmespath.TestJMESPathExtractor$SourceVarOrResponse
  0.0sec,   10 completed,   0 failed,   0 skipped, 
org.apache.jmeter.extractor.json.jmespath.TestJMESPathExtractor$MatchNumberMoreThanZeroOn1ExtractedValue
  0.0sec,6 completed,   0 failed,   0 skipped, 
org.apache.jmeter.extractor.json.jmespath.TestJMESPathExtractor$MultipleMatchesOnAllExtractedValues
  0.0sec,6 completed,   0 failed,   0 skipped, 
org.apache.jmeter.extractor.json.jmespath.TestJMESPathExtractor$OneMatchOnAllExtractedValues
  0.3sec,   32 completed,   0 failed,   0 skipped, 
org.apache.jmeter.extractor.json.jmespath.TestJMESPathExtractor
  0.0sec,   27 completed,   0 failed,   0 skipped, 
org.apache.jmeter.assertions.jmespath.TestJMESPathAssertion$TestAssertion
  0.0sec,   27 completed,   0 failed,   0 skipped, 
org.apache.jmeter.assertions.jmespath.TestJMESPathAssertion
  0.1sec,6 completed,   0 failed,   0 skipped, 
org.apache.jmeter.timers.UniformRandomTimerSpec
  0.2sec,3 completed,   0 failed,   0 skipped, 
org.apache.jmeter.visualizers.backend.influxdb.InfluxdbBackendListenerClientSpec
  0.4sec,5 completed,   0 failed,   0 skipped, 
org.apache.jmeter.visualizers.backend.graphite.TextGraphiteMetricsSenderSpec
  0.1sec,7 completed,   0 failed,   0 skipped, 
org.apache.jmeter.visualizers.backend.graphite.PickleGraphiteMetricsSenderSpec
  0.1sec,4 completed,   0 failed,   0 skipped, 
org.apache.jmeter.control.RandomOrderControllerSpec
WARNING   0.0sec,5 

Re: Groovy 2.4.18 vs Java 14

[Antonio Gomes Rodrigues]

+1

Le sam. 28 mars 2020 à 14:53, Felix Schumacher <
felix.schumac...@internetallee.de> a écrit :

>
> Am 28.03.20 um 14:30 schrieb Vladimir Sitnikov:
> > Hi,
> >
> > AFAIK, the version of Groovy we use 2.4.18 does not support Java 14.
> >
> > Should we upgrade?
> > There are two options: 2.5.10 (see
> > http://groovy-lang.org/changelogs/changelog-2.5.10.html ) and 3.0.2 (
> > http://groovy-lang.org/changelogs/changelog-3.0.2.html )
> >
> > Does anybody have any preference?
> >
> > I think it might be ok to go with 3.0.2
>
> +1
>
> Felix
>
> >
> > Vladimir
> >
>

Re: Groovy 2.4.18 vs Java 14

[Felix Schumacher]

Am 28.03.20 um 14:30 schrieb Vladimir Sitnikov:
> Hi,
>
> AFAIK, the version of Groovy we use 2.4.18 does not support Java 14.
>
> Should we upgrade?
> There are two options: 2.5.10 (see
> http://groovy-lang.org/changelogs/changelog-2.5.10.html ) and 3.0.2 (
> http://groovy-lang.org/changelogs/changelog-3.0.2.html )
>
> Does anybody have any preference?
>
> I think it might be ok to go with 3.0.2

+1

Felix

>
> Vladimir
>

Groovy 2.4.18 vs Java 14

[Vladimir Sitnikov]

Hi,

AFAIK, the version of Groovy we use 2.4.18 does not support Java 14.

Should we upgrade?
There are two options: 2.5.10 (see
http://groovy-lang.org/changelogs/changelog-2.5.10.html ) and 3.0.2 (
http://groovy-lang.org/changelogs/changelog-3.0.2.html )

Does anybody have any preference?

I think it might be ok to go with 3.0.2

Vladimir

Re: Undo/redo: does anybody use it?

[Vladimir Sitnikov]

>Nice work for a first shot !

Thanks. I think I'll merge it shortly.

So far it looks good to me, and it invalidates the history as the tree
selection is changed.

Frankly speaking, I have no idea on the generic way to associate the fields
to components yet.
In other words, if we want to associate edit history with components (e.g.
allow the user to switch between components and undo individual actions),
then we need to associate undo/redo history with the component rather with
the edit field.
However, that looks like an invasive change since it would require
JMeterGUIComponent#modifyTestElement (or something like that) to push/pop
the history.

Vladimir

Re: TristateCheckBox vs look and feels

[Vladimir Sitnikov]

Just in case, I've added a workaround to TristateCheckBox so it no longer
fails with NPE.

Vladimir

Re: TristateCheckBox vs look and feels

[Antonio Gomes Rodrigues]

Hi,

In my opinion we need only 1 LaFs with different color themes

I vote response 3


Le jeu. 26 mars 2020 à 21:04, Vladimir Sitnikov 
a écrit :

> Hi,
>
> We provide a menu option to select Look and Feel.
> I'm not sure which of them are used often, however, multiple LaFs come at a
> cost.
>
> For example, TCP Sampler UI
> uses org.apache.jmeter.gui.util.TristateCheckBox which has multiple hacks
> for different LaFs.
> TristateCheckBox relies on defaults.get("CheckBox.icon") which is null in
> case Daflkaf theme.
> On top of that, it is hard to tell what the third state means. The UI is
> obscure, and the documentation says nothing on the third state of the
> checkbox.
>
> So I have a couple of questions:
> 1) Should we replace TCP Sampler UI to use regular checkbox rather than a
> tristate one?
> 2) Should we refrain from implementing custom components?
> I'm inclined to drop TristateCheckBox completely rather than trying to fix
> that control to support the current LaFs.
> In practice, it would take time to develop and test custom-painted UI
> components across multiple looks.
> 3) What if we reduce the number of LaFs that we "support"? I do not think
> users really need different **styles** of UI.
> It should be enough if we provide an option to use different color themes
> like "light, dark, contrast, etc, etc".
>
> Vladimir
>

Re: Undo/redo: does anybody use it?

[Philippe Mouawad]

Nice work for a first shot !

On Fri, Mar 27, 2020 at 11:49 PM Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:

> I've created a draft undo/redo implementation for text fields:
> https://github.com/apache/jmeter/pull/576
>
> Of course, it needs special treatment when tree selection changes, however,
> even just the very basic ctrl+z
> would be way better than nothing.
>
> Any thoughts?
>
> Vladimir
>


-- 
Cordialement.
Philippe Mouawad.