Release 5.3
Hi, It's been a long since JMeter 5.2.1, so I guess 5.3 is long overdue. How about we release JMeter 5.3? Vladimir
Re: NoThreadClone should be used more often
>https://github.com/JCTools/JCTools) instead of Dexx HashMap? They serve for completely different use cases. JCTool's map is for concurrent operation (like Java's ConecurrentHashMap). That is when a map needs to be accessed from multiple threads, and each thread should see updates that come from the other threads. However, JMeter needs quite the opposite. JMeter needs a map that pretends to be **non-shared**. I other words, the map should support updates, however, each thread should see **only** its own updates. What JMeter currently does it **clones** maps. So a single "FlowControlAction" is stored millions times in the Java heap since JMeter clones the test plan for each and every thread. What we need is a way to share "the common values", however, all the updates must be put to separate storage. This is exactly what Dexx collections do. Of course, Dexx is not the only implementation, however it was the best for performance-memory footprint ratio when I explored the libraries some time ago for https://github.com/vlsi/compactmap Vladimir
Re: NoThreadClone should be used more often
>What do you mean by unsafe ? Suppose the property in question is TestElement.gui_class If the code reads it as <>, then the property can't be modified, so it is safe to use a shared property instance. However, if the client code does <> then we have no idea what will happen next. The code might call <> or do something else. That is why it is not safe to share the properties that were exposed outside of AbstractTestElement class. >For me this should be 6.0 (even if it's backward compatible), >it's a major change that needs to be highlighted. That is true. Async executor would indeed qualify as 6.0. Vladimir
Re: NoThreadClone should be used more often
>Custom scripts can also modify props (I guess you have this in mind, but >just not to skip it) That is true. I expect that all calls to "public JMeterProperty getProperty(String key)" should be treated as unsafe. Frankly speaking, it would probably be great if we could split configuration and execution phases. Currently, JMeter uses the same object (e.g. AbstractSampler) to configure the behavior in the test plan, and the very same object is used for the execution. However, the goals there are completely different: 1) Configuration needs backward compatibility (e.g. load old test plans), configuration needs various setters, generic visitor for "search substring" features, and so on 2) Execution needs much less. It does not need UI, it needs no backward compatibility. It just needs enough information to execute stuff. It would be much better if we removed org.apache.jmeter.testelement.AbstractTestElement#setRunningVersion and replaced it with something like `AbstractTestElement#getExecutorNode()` Then we would be able to build the executable test plan just once and skip cloning the test plan nodes altogether. Unfortunately, it is not clear how much effort would it take to rewrite the existing samplers and the controllers to the new approach :( So the plan could probably be like: JMeter 5.3 or 5.4: rewrite org.apache.jmeter.testelement.AbstractTestElement#propMap to use Dexx HashMap; add coroutine-based executor. That would unlock testing with high number of threads. JMeter 6.0: split AbstractTestElement into "configuration" and "execution" classes Vladimir
Re: NoThreadClone should be used more often
>a) Implement copy-on-write like mode for properties. >For instance, we can add `modifiedPropMap` for the properties that were modified in the running version. copy-on-write seems trivial to implement (e.g. replace Map with Dexx HashMap: https://github.com/andrewoma/dexx ), however, there's a major problem: JMeterProperty is exposed in a raw fashion (e.g. #getProperty or even #propertyIterator) It means we should clone properties at the time they are exposed to the untrusted code. However, it is not clear how to tell if the property was already cloned or not. Vladimir
Re: [Bug 64287] WhileController: Improve UX
Philippe, Thanks for doing the cleanup. I deliberately refrained from touching individual components :) However, can you please clarify what is the value of those one-time Bugzilla issues? They do appear in the email notifications, so they produce some noise. Later the end-users would crawl over the fixed bugs listed in the changelog, and they will not know if the bug is a true one or if it is an empty one. So these "empty Bugzilla entries" distract both developers and the end-users :-/ I guess we should commit small UX changes without creating Bugzilla tickets. On the other hand, it would be great to have screenshots (e.g. in the changelog) for the changes. That would be more valuable for the end-users, so they would learn how it works. PS. Some of the components you edit have significant padding around the panel. For instance, While Controller has significant padding for "Conditition (function or variable)" field. I guess we should stick to the following: 1) If a component contains just a set of fields, then padding should be minimal (e.g. like in Debug Sampler where the component panel has no padding around) 2) If there are titled panels, then the padding should be there. For instance, Thread Group has two titled panels, so the contents of the panels is padded. Vladimir
Re: [jmeter] branch master updated: Bug 64283 - XPath2 Extractor: Improve UX
+mainPanel.add(createScopePanel(true, true, true),
BorderLayout.NORTH);
+ <-- trailing whitespace
+JPanel panel = new JPanel(new MigLayout("fillx, wrap 2",
"[][fill,grow]"));
Phillippe, just wondering: I guess there's EditorConfig plugin for your IDE
(or a setting to trim trailing whitespace in Java files).
Have you tried it?
I guess it should completely prevent the appearance of the trailing
whitespace.
Vladimir
Re: [jmeter] branch master updated: Bug 64280 IfController: Improve UX
> +conditionPanel.setBorder(BorderFactory.createEtchedBorder()); // $NON-NLS-1$ Philippe, please remove the etched border. It adds visual noise for no reason. I'm inclined that we should forbid the use of BorderFactory.createEtchedBorder() Vladimir
NoThreadClone should be used more often
Hi, I've noticed that we have just a few cases when NoThreadClone is used. It results in enormous memory consumption since the test plan is effectively duplicated for each and every thread. Just in case: my testcase is 1 thread group (100'000 threads), 10 transaction controllers (each has one FlowControlAction, and one Constant 30sec timer). The test does not fit within 2Gb RAM :-( AFAIK there are three types of elements: * (almost) Stateless. For instance, UniformRandomTimer has no fields, and it does not even access its own properties. Note: there's `getRandom()` which is now implemented as `ThreadLocalRandom.current()` so it is thread-safe * Semi-stateless. For instance, TestAction. It does have a state for cancellation purposes (it needs to remember which thread to cancel) * Elements that do hold state. For example, TransactionController has quite a few fields I think we should do something with that, otherwise, the memory consumption is insane. I see the following possibilities: a) Implement copy-on-write like mode for properties. For instance, we can add `modifiedPropMap` for the properties that were modified in the running version. Then we could share the same property map and newly modified properties (if any) would go another map. That would save a lot of memory by small changes to the core alone. Just some numbers: 400'000 TestActions retain 315MiB in the heap, and the most part of it (300MiB) is consumed by property maps b) Apply NoThreadClone when possible. Note: `NoThreadClone` interface propagates for the derived classes, however, it might be the case that the derived class does have state, thus it requires cloning. So I think we might need to add `@ThreadClone` annotation which would enable us to specify different cloning behaviors for parent and derived classes. Then we might want to add a test case that ensures all in-core components either support NoThreadClone or explicitly declare that they do not support it. c) Consider dropping some attributes when making a runtime version. For instance, TestAction has the following properties: ActionProcessor.action ActionProcessor.duration ActionProcessor.target TestElement.enabled TestElement.gui_class TestElement.name TestElement.test_class TestElement.comments I guess gui_class and test_class are not really required for the running version. It might play well with annotation: `@ThreadClone(excludeProperties=["...gui_class", "test_class"])` Any thoughts? Vladimir
Re: Darklaf Intellij: when element is disabled its label is not readable Inbox x
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
Re: Screenshots: documentation, pull requests
>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
Groovy 2.4.18 vs Java 14
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?
>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
Just in case, I've added a workaround to TristateCheckBox so it no longer fails with NPE. Vladimir
Re: Undo/redo: does anybody use it?
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
TristateCheckBox vs look and feels
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?
>a) when component UI is created, we can scan the component hierarchy, and add the listeners to all JTextField-like objects in the tree >I'm inclined to #a because changing all new JTextField with new JMeterTextField would look like changing 100500 files out of thin air. It looks like there's yet another option: override TextFieldUI property in Swing's UIDefaults. Then JMeter could provide its own UI class. Then we could transparently support undo/redo listeners for all the fields, including plugin-provided GUI classes. Vladimir
Screenshots: documentation, pull requests
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
Re: Replacing nashorn
There might be yet another option. It might be that Nashorn would be moved to a community-managed library (e.g. like JavaFx became OpenJFX). >Is Nashorn or its replacment needed for *all* test plans? Some of the plans depend on Nashorn, and some of them do not. Vladimir
Re: Undo/redo: does anybody use it?
>Indeed, undo is only within current active selection. Ok. I just thought we could start with `undo for edit fields within the current tree selection`. In other words, reset all undo history when the test plan element is re-selected. I guess we could be able to release that activated by default, so people could start using undo/redo. A bit of a problem with that is it is required to attach undo listeners to all the fields, and the fields can even be created dynamically :-/ I see two approaches: a) when component UI is created, we can scan the component hierarchy, and add the listeners to all JTextField-like objects in the tree b) require that all JTextField must pass through a special API to add undo listeners Any thoughts on that? I'm inclined to #a because changing all new JTextField with new JMeterTextField would look like changing 100500 files out of thin air. Vladimir
Re: Undo/redo: does anybody use it?
sebb>My point was that the working copy of the test plan is complicated and fragile Well, the solution is to add synchronization (e.g. read-write locks) and forbid non-synchronized access to the model. That, however, is an orthogonal story. Vladimir
Re: Undo/redo: does anybody use it?
>Scripting elements like JSR223 and all elements using RSyntaxTextArea >already support this. Not quite. Suppose the following: 1) Create JSR223 Sampler 2) Type "hello" into the script field 3) Switch to Test Plan 4) Switch back to JSR223 Sampler ctrl+z does nothing. I would expect that history should persist across switching between elements. Vladimir
Re: Undo/redo: does anybody use it?
sebb>For example, even detecting whether the test plan has been changed I don't see why change detection is needed for undo. Philippe>Do you think it will be feasible to implement per-element undo/redo ? Philippe>ok by me anyway to have something in this field Yet another approach could be `per-field` undo. In other words, `ctrl+z` could undo the edits in the currently focused field. Vladimir
Re: Replacing nashorn
up. Graal.JS seems to be mature now. It can run on any Java machine: https://github.com/graalvm/graaljs/blob/master/docs/user/RunOnJDK.md#run-graalvm-javascript-on-a-stock-jdk The licenses there are MIT and/or UPL (both are permissible for Apache) The sad thing is that Graal.JS is ~20 megabytes extra. It is extremely likely Nashorn will be removed from Java 15, so we need to deal with it somehow. So the options are: a) Bundle Graal.JS (+20MiB :( ) b) Document the way to add Graal.JS jars as an external dependency (everybody would need to download the file manually :( ) c) Add an option to download Graal.JS on demand (not that trivial to implement, yet useful for many(!) other cases) WDYT? Vladimir
Re: Comments field vs moving focus: tab vs ctrl+tab
Ok, great. Now's a more tricky question: should we patch all the multiline fields or should we do it case by case? For instance: how about JSR223 code editors? Vladimir
Comments field vs moving focus: tab vs ctrl+tab
Hi, Every JMeter component has Name and Comments. "Comments" is a multi-line field (which is nice for writing comments), but it does not play well with moving focus via tab and shift+tab. If you hit `tab` inside Comments field, then you just add a tab character (like an indentation). Of course, there's a way to move focus, and it is ctrl+tab and ctrl+shift+tab, however, it looks weird for me. Does that make sense? Frankly speaking, I think using tabs for indentation inside Comments field is an edge case, so I would suggest we re-configure `tab` meaning for Comments field. Any thoughts? Vladimir
Undo/redo: does anybody use it?
Hi, I see undo was added ~6 years ago, however, it is still disabled by default :( The lack of undo can easily be the top priority issue for the users. >From what I understand, the current implementation is to build a global history across all test plan elements. It does not feel right, because the test plan is often a mix of loosely coupled items (e.g. different thread groups represent completely different test items), so it looks like undo/redo should be per-element rather than global. Just in case: IntelliJ IDEA seems to implement per-file undo/redo, so ctrl+z (cmd+z) reverts actions in the current file. What do you think if we make undo per-element? Vladimir
Re: [jmeter] branch master updated: Error when loading Templates on Windows
>-Document document = bd.parse(file.getAbsolutePath()); >+Document document = bd.parse(file.toURI().toString()); Felix, is there a reason why bd.parse(file) is not used? Vladimir
Re: failing timeshift test
>interpretation of LocalTime addition operations and parsing Well, the function itself does a lot of time parsing, so I am nowhere sure if it contains bug or not. Did you mean the test fails at the specific date only? However, the concurrent execution of tests that alter timezone is not something we intended to do. Technically speaking, JUnit5 has ResourceLock notation (see https://github.com/junit-team/junit5/issues/2142#issuecomment-596199239 ) Vladimir
Re: [jmeter] branch master updated: Apply autostyle to make spotbugs happy
Felix> new 1673248 Apply autostyle to make spotbugs happy 1) Technically speaking, this has nothing to do with spotbugs. 2) If you install editorconfig plugin, it would likely insert the final newline automatically (see insert_final_newline in .editorconfig) Vladimir
Re: failing timeshift test
I guess the issue there is the test relies on TimeZone.getDefault(), however, there's org.apache.jmeter.functions.TestDateTimeConvertFunction#testDateTimeConvertEpochTime which alters the default time zone. Let's see if something like https://github.com/apache/jmeter/pull/560 can workaround this. Vladimir
Re: Darklaf - A themeable swing Look and Feel based on Darcula-Laf
>Properties, XML, etc are not executed by the JVM; they are effectively >just data. BeanShell, JavaScript, and Groovy are not "just data", but it is code which is a part of JMeter. So far I see no technical justification for requiring all transitive dependencies to be written in Java language only. Vladimir
Re: Darklaf - A themeable swing Look and Feel based on Darcula-Laf
>No, that's not exactly what 100% pure Java code means Pure Java means nothing. JMeter has lots of Properties, XML, XSLT, CSS, Groovy, BeanShell, and even, holy cow, JavaScript files. There's no point in making "100% pure X" without having a good definition of that. >The Java code must of course comply with the appropriate Java language >Is Darklaf written entirely in Java? >Are all its dependencies written in Java? It is Java virtual machine compliant. Why does the language matter to you? Vladimir
Re: Darklaf - A themeable swing Look and Feel based on Darcula-Laf
>Huh? Ok, so you mean Java specification. In that sense, Darklaf follows the spec, and its code should be compatible with all Java virtual machines. Vladimir
Re: Darklaf - A themeable swing Look and Feel based on Darcula-Laf
>Will JMeter remain 100% pure Java? Sorry, I don't understand the question. What do you mean by 100% Java? >Are there really no standard LAFs that would suit JMeter? 1) Standard LAFs do not look and feel modern 2) No standard LAF has a dark scheme that might work better in the evening. Vladimir
Re: Darklaf - A themeable swing Look and Feel based on Darcula-Laf
>JMeter is advertised as being 100% pure Java code. Darklaf has a native integration feature, however, it is optional. Currently, JMeter uses Darcula as a default look and feel now, there are multiple UI bugs in Darcula (e.g. tree indent is hard to see), Darcula has a single release only, nobody's going to fix Darcula issues in Darcula itself, because the code is just stale. So I think we should drop Darcula theme completely, and migrate to Darklaf ( https://github.com/weisJ/darklaf ) or FlatLaf ( https://github.com/JFormDesigner/FlatLaf ) So far, Darklaf maintainer fixed all the JMeter-related LaF issues, and I think JMeter can just migrate to that LaF. The challenge for JMeter is that Darklaf uses **extensible** theming, so it is a single LaF with an ability to have multiple themes. JMeter's menu does not support that, and we probably need to configure that somehow (e.g. creating a submenu for themes). Vladimir
Re: Darklaf - A themeable swing Look and Feel based on Darcula-Laf
> * it seems to takes more screen space than the other themes (just a feeling) It was a bug in Combobox rendering: https://github.com/weisJ/darklaf/issues/38 It is fixed. >* dragable separators are hard to see (on my setup). I can only see the drag-handles I guess even the old Darcula renders the handles only. It looks like Darklaf defaults to no-border JPanel while Darcula renders 1px black border which sometimes looks like a divider. Vladimir
Re: [jmeter] branch master updated: Try to cleanup gradle cache for bouncycastle on travis
>Probably different caches? I'm not sure, but it looks plausible that .asc resolution failed, and it was cached somehow. Can you try dropping the cache and restarting the job (there's UI as well for that) Vladimir
Re: [jmeter] branch master updated: Try to cleanup gradle cache for bouncycastle on travis
Felix, just in case, there's "drop cache" button in the UI: https://travis-ci.org/apache/jmeter/caches Vladimir
Re: Darklaf - A themeable swing Look and Feel based on Darcula-Laf
>Does it silently default if it fails to bind to dll or does it break ? No idea. The full thing works in my macOS. It might work as well if excluding jna dependency, however I have not tried that. Vladimir
Re: Darklaf - A themeable swing Look and Feel based on Darcula-Laf
>Just wondering, why does it rely on jna ? I guess it is for https://github.com/weisJ/darklaf/wiki/Features#native-window-decorations (which is Windows-only for now) Vladimir
Re: Darklaf - A themeable swing Look and Feel based on Darcula-Laf
>But the glitches for now seem blocking no ? Well, checkbox/radio glitch is already fixed (~3-4 hours time from issue to resolution), so the author is quite open with fixing issues, and they do publish the library to Central. The key issue left is license clearance + fixing minor issues. In my opinion, it is more-or-less ready for JMeter. That would enable us to keep momentum. An alternative option is to migrate to something like https://tornadofx.io/ , however, that is a bit different story. The dependencies are something like the following: +--- com.github.weisj:darklaf -> 1.3.3.4 |+--- com.metsci.ext.com.kitfox.svg:svg-salamander:0.1.19 |+--- net.java.dev.jna:jna:4.1.0 |\--- org.swinglabs:jxlayer:3.0.4 Vladimir
Re: Darklaf - A themeable swing Look and Feel based on Darcula-Laf
>Yes, it is looking really nice. OK. I've tried it, and it seems to work, however, there are glitches :( The most interesting bit is jxlayer-3.0.4.jar dependency. AFAIK the library was initiated at http://swinglabs.org/ which is no longer available. The jar file does not bundle the license text. I don't think the original repository is alive. I guess the license of the artifact is BSD-3-Clause (==> it requires to reproduce the copyright header), so technically speaking we must somehow resurrect the copyright owner if we want to include that dependency :) I'm not that good at resurrection, however, it looks like this looks ok: https://github.com/tsachev/jgnash/blob/25a5ad1f9349cf9f2849509c09a24f8b1fa3cbf5/jgnash-resources/src/main/resources/jgnash/resource/html/en/jxlayer-license.html Here's a PR with minimal change to make it fly: https://github.com/apache/jmeter/pull/556 I've filed a couple of issues to darklaf as well. Vladimir
Darklaf - A themeable swing Look and Feel based on Darcula-Laf
Hi, It looks interesting: https://github.com/weisJ/darklaf/wiki/Features Vladimir
Re: batchTestRedirectionPolicies fails too often
Just in case: https://github.com/vlsi/jmeter/runs/411635373 (both macOS and Windows jobs failed because of redirection policies) https://github.com/apache/jmeter/pull/553/checks?check_run_id=411635502 the same thing The same thing for ALL Travis jobs: https://travis-ci.org/apache/jmeter/builds/642583544 The test breaks 8 CI jobs of 8 which does not look great. Vladimir
Re: batchTestRedirectionPolicies fails too often
>Is there a better way to test the same functionality? The tests should not connect to external servers unless the server is known to be stable. For now, we have multiple tests that access external systems, and they fail quite often. Vladimir
batchTestRedirectionPolicies fails too often
Hi, I see that batchTestRedirectionPolicies fails too often (more than 50% of the times?) which is sad. I'm inclined to disable the test. Any thoughts? Vladimir
Replace Spotless with Autostyle
Hi, I intend to replace Spotless with Autostyle ( https://github.com/autostyle/autostyle) in our build. The net result will be the license headers will be more consistent, and the style violation messages will be easier to understand. For instance, Autostyle is capable of automatic license formatting for XML and Shell files. PR: https://github.com/apache/jmeter/pull/549 Unfortunately, the PR touches a lot of files, however, it should not hurt much. spotlessCheck task will be replaced with autostyleCheck spotlessApply -> autostyleApply style task will still work (it applies the changes and verifies the rest) Vladimir
Re: httpclient4.time_to_live defaults to 2000 which is way less than the typical browser behavior
>more connections on the client, which can be a sparse resource. It does not typically exceed the number of threads, so users would expect that. The problem with the current default is it makes the false sense of enabling keep-alive in UI. The users might think that they activate KA, but it is not used if the response times exceed 2sec. Reusing connections after 60seconds might even enable to surface concurrency issues in the app. Vladimir
Re: Hardcoded setEnableAutoCommitOnReturn=false
Philippe>dataSource.setEnableAutoCommitOnReturn(isAutocommit()); What do you think of adding a checkbox like "rollback on returning connections to the pool"? Dmitry>I've created issue. Currently I can't find solution for that without Dmitry>changing source code :( I guess it would make sense to make it configurable. Vladimir
Re: Hardcoded setEnableAutoCommitOnReturn=false
>Here is the example jmx file It looks like the attachment was cut :( https://lists.apache.org/thread.html/651e4cd6d9bebabc1a70766d01b2030c3e72ecdcd83d1c513558f99a%40%3Cdev.jmeter.apache.org%3E Vladimir
Re: Hardcoded setEnableAutoCommitOnReturn=false
Dmitry>I'm facing problem while I'm testing Derby DB - when 2 connection used Dmitry>(first with autoCommit=true and other with autoCommit=false) exception Dmitry>occurs while switching between this 2 connections inside test. Can you please provide a minimal reproducible example (e.g. jmx file)? It was added in https://github.com/apache/jmeter/commit/e15602def76e4472a689aadae25b2d7b2ea0cd97 , and it probably makes sense to make the option configurable. java.sql.Conneciton#close with a pending transaction is not specified indeed, and Derby has chosen to throw in such a case. Vladimir
httpclient4.time_to_live defaults to 2000 which is way less than the typical browser behavior
Hi, JMeter defaults to 2 seconds timeout for keep-alive HTTP connections, which seems to be much less than the typical browser configuration. https://en.wikipedia.org/wiki/HTTP_persistent_connection#Use_in_web_browsers , https://fastmail.blog/2011/06/28/http-keep-alive-connection-timeouts/ suggest that: IE: 60 sec FireFox: 115 sec Chrome: 300 sec What do you think if we bump the default for httpclient4.time_to_live from 2000 to 12 (==2 min)? I guess the current setting of 2000 was just a copy-paste result when the setting was initially implemented. Here's the commit that introduces the feature: https://github.com/apache/jmeter/commit/eaaf1be40908ba5f74e7baac9ea985cc62de6a6f#diff-4e3471b25c91730a99ed23402467b9eaR146 Vladimir
Re: [OpenIV:0551] Re: Bugzilla Enhancement: "Auto-Correlation as core functionality in JMeter"
>About new feature of auto-correlation, we prepared specification written as manual. That is great. It really helps to preview the feature. However, I fail to understand what is "correlation with JMX file". I see it consumes an extra JMX file, but it is not clear what should be there in the file, it is not clear what is added as a result. Does "Correlation" differ from "Auto-Correlation"? Should just one of them be used in all the places? Is there a "manual correlation"? How Rule differs from Correlation? Is Rule mandatory for Correlation to work? Vladimir
Re: [VOTE] Release JMeter 5.2.1 RC5
Thanks, +1 Artifacts look good, jks is not included to the binary archives. Vladimir
Re: Cleaning the /src/dist/build/distributions directory before put the archives
>it's will be better to clean the distributions directory before >put the archives to avoid issues? Extra files do not bother me, and I even compare them sometimes. The contents of src/dist/build/distributions is never scanned for the list of files to publish, and I see no reason to clean it every time. You can execute gw clean (or ./gradlew :src:dist:clean) if you want before the release. You can use gradlew :src:dist:clean prepareVote ... as well. Vladimir
Re: [VOTE] Release JMeter 5.2.1 RC4
I guess it is up to RM, but I do not think those are significant issues. It takes too much time to vote/announce, so redoing RC for minor issues seems to be a waste of time. Vladimis
Re: [VOTE] Release JMeter 5.2.1 RC4
>it could be moved to a test resources directory instead I agree. We should refrain from mixing production code with testing code in the same folder. Vladimir
Re: [VOTE] Release JMeter 5.2.1 RC4
>It's also in the source release and in the Git repo, so I assume it is >supposed to be there. That depends. It might be in the source repo for testing purposes only. So I would suggest we keep it in the source distribution (otherwise source build would fail), and we exclude the file from the binary distribution to prevent users from accidental use of rmi_keystore.jks. Vladimir
Re: [VOTE] Release JMeter 5.2.1 RC4
Just a side note: the release step (gw publishDist) is known to fail if SVN 1.9 is used (see https://issues.apache.org/jira/browse/SVN-4666 , https://github.com/vlsi/asflike-release-environment/issues/1) I guess Milamber is using a newer version (since the previous release succeeded), however, I would suggest double-checking. The error does not happen for me with SVN 1.12.2 though, and the next version of the release plugin implements a workaround. We can upgrade after the release. Vladimir
Re: [VOTE] Release JMeter 5.2.1 RC4
>The fourth release candidate for JMeter 5.2.1
Thank you
+1: I verified checksums, signatures, build, tests, pom files
JMeter from binary distribution starts.
--- script
VER=5.2.1
RC=4
svn checkout
https://dist.apache.org/repos/dist/dev/jmeter/apache-jmeter-$VER-rc$RC
cd apache-jmeter-$VER-rc4
for i in *.asc; do gpg --verify $i; done;
for i in *.zip *.tgz; do shasum -a512 $i; done;
tar xzf apache-jmeter-${VER}_src.tgz # or unzip apache-jmeter-${VER}_src.zip
cd apache-jmeter-${VER}
./gradlew build -Prelease -PskipSigning
Vladimir
Re: [VOTE] jmeter-test.apache.org for site preview
Thanks, The vote passes with +4: Vladimir, Philippe, Felix, Antonio. Vladimir
[VOTE] jmeter-test.apache.org for site preview
Hi, We are using GitHub pages for 'site preview' during release. In https://issues.apache.org/jira/browse/INFRA-19395 I asked to create robots.txt to disallow indexing of the preview site ( https://apache.github.io/jmeter-site/... ) It turns out we can have a CNAME (see INFRA-19395), so https://jmeter-test.apache.org points to GitHub Pages site. The SSL certificates would be automatic. What do you think regarding jmeter-test.apache.org ? +1: I support jmeter-site.a.o -1: I do not like the idea because... Here's my vote: +1 Vladimir
Re: Release 5.2.1
Milamber, would you please retry creating RC? Vladimir
Re: [jmeter] branch master updated: Get focus on the RC Number in word and the description of the release
>+The [RC NUMBER] release candidate What do you mean by [RC NUMBER] ? Could you just use $rc variable instead ? Vladimir
Re: [jmeter] branch master updated (7850afb -> 79bda1b)
Ok. I see you've made the screenshot to be much wider (687px -> 1055px): https://github.com/apache/jmeter/commit/79bda1b4ea1eb9494811ca0c166ccca85bebf818?short_path=10973a0#diff-10973a05c7bd6dbecfcee858f78121b1 Does it help readability? I doubt so. So, would we please enable force-push and shrink the image? Vladimir
Re: [jmeter] branch master updated (7850afb -> 79bda1b)
>Bin 26380 -> 37115 bytes Philippe, have you compressed the image? It is yet another reason to enable force-push. If a big file suddenly committed, it would be hard to get rid of it. Vladimir
Re: Release 5.2.1
>I will try to do a RC2 of v5.2.1 tonight My bad. The latest snapshot (gradle-6.0.1-20191114002542+-all.zip) does not include the fix yet. So let's try tomorrow. Vladimir
Re: Release 5.2.1
It seems rather restrictive that repository.apache.org is not ready for sha256 in 2019. Vladimir
Re: Release 5.2.1
>Are we sure it will be available in 1 week ? Please have a look over the recent patch releases: https://gradle.org/releases/ They were quite prompt. For instance: Gradle 5.2 (Feb 04), 5.2.1 (Feb 08). We are not voting that fast yet :-/ If it does not appear in a week, we can revert to 5.6. Vladimir
Re: Release 5.2.1
Update: it turned out repository.apache.org is not yet ready for storing sha256 and sha512 checksums. Gradle 6.0 publishes sha256 and sha512, however, Nexus is not ready yet. The relevant issue is https://issues.apache.org/jira/browse/INFRA-14923 Gradle issue is https://github.com/gradle/gradle/issues/11308 So we have at least two options: * Wait till 6.0.1 is released with a flag that disables 256/512 checksums * Revert Gradle to 5.6.2 and retry the release I would suggest waiting for Gradle 6.0.1 for a week. Vladimir
Re: Release 5.2.1
>That’s what is done with maven when you want to force a newer version than the one embedded by dependency Remember there are frameworks and there are libraries. binary distribution of JMeter is a framework: it enforces you to put jars into relevant places, and start with ./jmeter. On the other hand, jar files on Maven Central are libraries. They do not enforce the way you use them. The one who uses Maven artifacts is free to select the suitable versions. The rule for dependencies should be as follows: 1) If we use the class (e.g. in extends, method parameter or method returning value), then the dependency should be explicitly declared 2) If we do not use a dependency (e.g. we do not use asm explicitly), then the dependency should not be declared 3) The exception to #2 is the case when the transitive version is too old (e.g. contains security issue), then we could still declare an "unused dependency". Unfortunately, there's no validation for the dependencies yet, and I'm planning to implement one shortly. Vladimir
Re: Release 5.2.1
>Done. Why add asm? We do not use it => it should not be added. Vladimir
Re: Release 5.2.1
If Milamber has not yet started rc1, then we could add it. Otherwise, I do not think it is a notable issue for stopping the release. Vladimir
Re: [jmeter] branch master updated: prepare new version 5.2.1
>+ Ah. Need to get rid of this. Vladimir
Re: Release 5.2.1
Looks good to me. Milamber, would you please create a rc? Vladimir
Re: Release 5.2.1
>Following discovery of issue on pom, can we release a 5.2.1 ? +1 Vladimir
Re: [jmeter] branch master updated: build.gradle.kts in core, functions, components, protocol: Fix dependencies for pom generation and remove version
>Where ? https://github.com/apache/jmeter/blob/2cfdec9d50ddab4649b813c07724588a03371ef4/src/protocol/build.gradle.kts#L86 Vladimir
Re: [jmeter] branch master updated: build.gradle.kts in core, functions, components, protocol: Fix dependencies for pom generation and remove version
>1/ I reverted the ones that indeed look wrong. Thanks >2/ But I kept dec which is needed for http. Do you mean org.brotli:dec ? It was there. Vladimir
Re: [jmeter] branch master updated: build.gradle.kts in core, functions, components, protocol: Fix dependencies for pom generation and remove version
> For com.miglayout:miglayout-swing , isn't it missing ? It is declared in "core": https://github.com/apache/jmeter/blob/b0448c8cb3b70e7c3c58f84af926d0071a091f78/src/core/build.gradle.kts#L74 >- Is scope runtime in the poms correct ? It is Vladimir
Re: [jmeter] branch master updated: build.gradle.kts in core, functions, components, protocol: Fix dependencies for pom generation and remove version
>No, it's one of my concern but that's not what drives my commit. >The Pom are wrong and I am trying to fix it. That is fine. However, this time the fix is wrong, so I suggest to step back and revert it. >Can you explain instead of requesting revert ? Simple explanation: Gradle builds the code, and the resulting binary works. It means all the required jars are declared (either explicitly or they come with transitive dependencies) xpp3 is not used by JMeter code, so the library should not be in the dependencies. In other words, org.xmlpull classes never appear in the source code of JMeter, so the library should not be in the dependencies. As you can see below, xpp3 is used by xtream:jar, and it is declared in the pom file for com.thoughtworks.xstream:xstream:jar:1.4.11 (see https://repo1.maven.org/maven2/com/thoughtworks/xstream/xstream/1.4.11.1/xstream-1.4.11.1.pom ) $ mvn -f src/core/build/publications/core/pom-default.xml dependency:tree [INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ ApacheJMeter_core --- [INFO] org.apache.jmeter:ApacheJMeter_core:jar:5.2.1-SNAPSHOT [INFO] +- org.apache.jmeter:ApacheJMeter:jar:5.2.1-SNAPSHOT:compile [INFO] +- org.apache.jmeter:jorphan:jar:5.2.1-SNAPSHOT:compile [INFO] | +- org.slf4j:slf4j-api:jar:1.7.28:compile [INFO] | +- commons-io:commons-io:jar:2.6:runtime [INFO] | \- org.apache.commons:commons-lang3:jar:3.9:runtime [INFO] +- bsf:bsf:jar:2.4.0:compile [INFO] | \- commons-logging:commons-logging:jar:1.0.4:compile [INFO] +- com.fifesoft:rsyntaxtextarea:jar:3.0.4:compile [INFO] +- net.sf.jtidy:jtidy:jar:r938:compile [INFO] +- com.thoughtworks.xstream:xstream:jar:1.4.11:compile [INFO] | +- xmlpull:xmlpull:jar:1.1.3.1:compile [INFO] | \- xpp3:xpp3_min:jar:1.1.4c:compile ^^^ here [INFO] +- org.apache.logging.log4j:log4j-1.2-api:jar:2.12.1:compile [INFO] +- org.apache.logging.log4j:log4j-api:jar:2.12.1:compile [INFO] +- org.apache.logging.log4j:log4j-core:jar:2.12.1:compile [INFO] +- org.apache.logging.log4j:log4j-slf4j-impl:jar:2.12.1:compile [INFO] +- org.apiguardian:apiguardian-api:jar:1.1.0:compile [INFO] +- oro:oro:jar:2.0.8:compile [INFO] +- xalan:xalan:jar:2.7.2:compile [INFO] | \- xalan:serializer:jar:2.7.2:compile [INFO] +- net.sf.saxon:Saxon-HE:jar:9.9.1-5:compile [INFO] +- org.slf4j:jcl-over-slf4j:jar:1.7.28:runtime [INFO] +- commons-codec:commons-codec:jar:1.13:runtime [INFO] +- commons-collections:commons-collections:jar:3.2.2:runtime [INFO] +- com.github.ben-manes.caffeine:caffeine:jar:2.8.0:runtime [INFO] | +- org.checkerframework:checker-qual:jar:2.10.0:runtime [INFO] | \- com.google.errorprone:error_prone_annotations:jar:2.3.3:runtime [INFO] +- com.fasterxml.jackson.core:jackson-annotations:jar:2.9.10:runtime [INFO] +- com.fasterxml.jackson.core:jackson-core:jar:2.9.10:runtime [INFO] +- com.fasterxml.jackson.core:jackson-databind:jar:2.9.10:runtime [INFO] +- com.miglayout:miglayout-swing:jar:5.2:runtime [INFO] | \- com.miglayout:miglayout-core:jar:5.2:runtime [INFO] +- org.freemarker:freemarker:jar:2.3.29:runtime [INFO] +- org.mozilla:rhino:jar:1.7.11:runtime [INFO] +- org.apache.xmlgraphics:xmlgraphics-commons:jar:2.3:runtime [INFO] +- org.apache.commons:commons-text:jar:1.8:runtime [INFO] +- org.apache.commons:commons-math3:jar:3.6.1:runtime [INFO] +- org.apache.tika:tika-core:jar:1.22:runtime [INFO] +- org.jodd:jodd-core:jar:5.0.13:runtime [INFO] +- org.jodd:jodd-props:jar:5.0.13:runtime [INFO] +- org.codehaus.groovy:groovy-all:jar:2.4.16:runtime [INFO] +- org.apache.tika:tika-parsers:jar:1.22:runtime [INFO] +- xerces:xercesImpl:jar:2.12.0:runtime [INFO] \- xml-apis:xml-apis:jar:1.4.01:runtime >http modules requires HttpClient, it's not referenced , as a > consequence corresponding pom is wrong See $ mvn -f src/protocol/http/build/publications/http/pom-default.xml dependency:tree ... [INFO] +- org.apache.httpcomponents:httpmime:jar:4.5.10:runtime [INFO] | \- org.apache.httpcomponents:httpclient:jar:4.5.10:runtime ... Vladimir
Re: [jmeter] branch master updated: build.gradle.kts in core, functions, components, protocol: Fix dependencies for pom generation and remove version
>So the commit is not incorrect. Please revert. I'm 100% sure the commit is incorrect. It seems you are driven by "the failure of jmeter-maven-plugin". However, the failure is caused by j-m-p itself, and adding unused dependencies to JMeter is not the right way to workaround j-m-p issue. Vladimir
Re: [jmeter] branch master updated: build.gradle.kts in core, functions, components, protocol: Fix dependencies for pom generation and remove version
>implementation("xpp3:xpp3_min")
>Used by core for persisting
This is very simple to check.
xpp3_min-1.1.4c.jar jar contains only org/xmlpull/... classes.
$ git grep xmlpull
checksum.xml:
gradle.properties:xmlpull.version=1.1.3.1
lib/aareadme.txt:xmlpull-1.1.3.1
lib/aareadme.txt:http://www.xmlpull.org/impls.shtml
src/bom/build.gradle.kts:apiv("xmlpull:xmlpull")
That is it. JMeter source code does not use org.xmlpull. classes, so
xpp3:xpp3_min dependency should not be added.
The same thing is for other dependencies.
Please revert the changes that add the dependencies.
Vladimir
Re: [jmeter] branch master updated: build.gradle.kts in core, functions, components, protocol: Fix dependencies for pom generation and remove version
The ones that you've just added:
+implementation("com.miglayout:miglayout-core")
+implementation("com.miglayout:miglayout-swing")
+implementation("org.ow2.asm:asm")
+implementation("xalan:serializer:xalan")
+implementation("xmlpull:xmlpull")
+implementation("xpp3:xpp3_min")
and so on.
I'm fine with removal of the versions, however, I'm not fine with adding
dependencies that are not actually used.
Vladimir
Re: [jmeter] branch master updated: build.gradle.kts in core, functions, components, protocol: Fix dependencies for pom generation and remove version
>Fix dependencies for pom generation and remove version Why are the dependencies added? They are not used by JMeter. Vladimir
Re: gw generatePom not generating pom files
>I thought running from there would generate for all projects Of course, it would. $ gw clean $ find . -name 'pom*.xml' | wc -l 0 $ gw generatePom -m ... :generatePom SKIPPED :src:components:generatePomFileForComponentsPublication SKIPPED :src:components:generatePom SKIPPED :src:config:generatePomFileForConfigPublication SKIPPED :src:config:generatePom SKIPPED :src:core:generatePomFileForCorePublication SKIPPED :src:core:generatePom SKIPPED :src:functions:generatePomFileForFunctionsPublication SKIPPED :src:functions:generatePom SKIPPED :src:jorphan:generatePomFileForJorphanPublication SKIPPED :src:jorphan:generatePom SKIPPED :src:launcher:generatePomFileForLauncherPublication SKIPPED :src:launcher:generatePom SKIPPED ... $ gw generatePom $ find . -name 'pom*.xml' ./src/launcher/build/publications/launcher/pom-default.xml ./src/core/build/publications/core/pom-default.xml ./src/config/build/publications/config/pom-default.xml ./src/protocol/junit-sample/build/publications/junit-sample/pom-default.xml ./src/protocol/ftp/build/publications/ftp/pom-default.xml ./src/protocol/native/build/publications/native/pom-default.xml ./src/protocol/bolt/build/publications/bolt/pom-default.xml ./src/protocol/junit/build/publications/junit/pom-default.xml ./src/protocol/mail/build/publications/mail/pom-default.xml ./src/protocol/ldap/build/publications/ldap/pom-default.xml ./src/protocol/java/build/publications/java/pom-default.xml ./src/protocol/mongodb/build/publications/mongodb/pom-default.xml ./src/protocol/jdbc/build/publications/jdbc/pom-default.xml ./src/protocol/tcp/build/publications/tcp/pom-default.xml ./src/protocol/http/build/publications/http/pom-default.xml ./src/protocol/jms/build/publications/jms/pom-default.xml ./src/components/build/publications/components/pom-default.xml ./src/functions/build/publications/functions/pom-default.xml ./src/jorphan/build/publications/jorphan/pom-default.xml Vladimir
Re: Version 5.2 (Broken poms)
Vladimir>The current error Just to clarify: I believe https://github.com/apache/jmeter/commit/ef06709a780bc776ecc3b5d839c424d39bb1aeae fixes the poms, and the current jmeter/master is ok. Vladimir
Re: gw generatePom not generating pom files
Philippe>But I see nothing in build/publications Are you sure? $ cd src/core $ gw generatePom $ grep -B 3 -A 3 jorphan build/publications/core/pom-default.xml org.apache.jmeter jorphan 5.2.1-SNAPSHOT Vladimir
Re: Version 5.2 (Broken poms)
Mark>Secondly we don’t use any local files, we pull binaries directly down from maven central using aether Mark>currently the plugin wouldn’t use them anyway Here you go: https://github.com/jmeter-maven-plugin/jmeter-maven-plugin/pull/345 The current error is "An error occurred: org/xmlpull/v1/XmlPullParserException" (see https://travis-ci.org/jmeter-maven-plugin/jmeter-maven-plugin/jobs/609714883#L3135 ), and I believe it has the same root cause as https://github.com/jmeter-maven-plugin/jmeter-maven-plugin/issues/187 Vladimir
Re: Git enable force push for master branches
Up. Any thoughts? This could have been prevented if force-push was enabled: https://github.com/apache/jmeter/commit/04aab12c68af8c57258c5ae905bd8b7ab0a2dd9f Vladimir
Re: [jmeter] branch master updated: ApacheJMeter_config.jar: Restore bin folder and add missing files
+text("templates.xml")
+text("*.jmx")
Those files were not here.
Are they required?
What is the test case for the jar?
Vladimir
Re: svn commit: r36676 - in /release/jmeter: binaries/ source/
I've added removeStaleArtifacts which is automatically run after publishing
the release to /release/jmeter/...
The task can be called manually:
$ gw removeStaleArtifacts -PasfDryRun -Pjmeter.version=5.2 # keep 5.2
artifacts, and print the files to be removed
$ gw removeStaleArtifacts -Pasf -Pjmeter.version=5.2 # keep 5.2 artifacts,
and remove the other files
The set of files to keep is configured in /build.gradle.kts
-> staleRemovalFilters { ... }
The missing bit is to drop stale Nexus staging repositories.
It could be implemented as
https://github.com/gradle-nexus/publish-plugin effort
stabilizes.
Vladimir
Re: Version 5.2 (Broken poms)
I reached out to jmeter-maven-plugin 3 month ago, and they did not seem to care: https://github.com/jmeter-maven-plugin/jmeter-maven-plugin/issues/339 Vladimir
Re: svn commit: r36676 - in /release/jmeter: binaries/ source/
>With the new build script, there is a Gradle task to do this ? It is not there yet. >Note: I use the (old) ant script to remove the v5.1.1 from the release site https://dist.apache.org/repos/dist/dev/jmeter/ still contains old files. Should they be removed after the release as well? Should the removal happen with moving artifacts from /dev/ to /release/? Vladimir
Re: Returned post for annou...@apache.org
Milamber>PS @vladimir can you fix this on the release plugin? The folder is configured in JMeter sources: https://github.com/apache/jmeter/blob/7fa6e9233b499c9a0c079c395a855331daccc8d5/build.gradle.kts#L126-L130 Vladimir
Re: Issue with last RC about SHA512 hashes
>issue: the generated email have twice "*apache-jmeter-5.2.xxx" on each > line. It is fixed now (~ https://github.com/vlsi/vlsi-release-plugins/commit/19e2a6e8330d3d10f80e7fed6503443362f69c07# ) Vladimir
Re: Returned post for annou...@apache.org
>source is singular because there is generally only one version of > source for OSes. I would suggest to update the download script accordingly because we have tgz and zip flavours of the sources. Plus we might happen to have multiple versions in the sources folder. Vladimir
Re: [ANNOUNCE] Apache JMeter 5.2 released
Many thanks to everybody involved. Vladimir
Re: Build failed in Jenkins: JMeter Ubuntu #929
sebb>I think the test harness is broken in this regard, and ought to be fixed. Ok. What do you typically do when an open-source project is broken or when it is missing a feature? sebb>It may still occur. The probability is extremely low, so it does not matter if it can occur or not. Vladimir> line numbers are the first thing to rely on sebb>I have always found it the most useful item of info I don't say line numbers are not useful. What I say is line numbers should not be treated as the first thing to look at. sebb>with editors one can go direct to the right place Build failure from builds.apache.org does not integrate with IDEs yet. Many people miss IDEs on their mobile phones/tables, and I test failure mails should be readable/understandable even without IDE/code editor. Vladimir
Re: Build failed in Jenkins: JMeter Ubuntu #929
sebb>So is there a way to fix this so the line number *is* shown? For instance: avoid extending test methods and use delegation instead of inheritance. sebb>Such an error is likely to occur again elsewhere Why do you think so? There are no more than 5 such cases (I would say 1-2, but 5 is very conservative) in JMeter sources, so it is very unlikely similar cases would occur elsewhere. It is far easier to just fix the assertion messages (if they ever occur) rather than discuss "oh, that is likely to occur". sebb>Unique messages are one way to achieve that if the test harness fails sebb>to provide that information, as in this case sebb>If the same message can appear in two places Yes, but that is missing my point. If the same message can appear in two places in the same test method then the test is **broken**. Remember that line numbers change over time (e.g. when tests are edited), and it is not the first thing to rely on. In other words, assert messages should be good enough even without line number/stacktrace. Vladimir
