On Friday, October 4, 2019, Vladimir Sitnikov <[email protected]> wrote:
> >I propose to drop it for this release 5.2 > > This is interesting. > Do we need Bolt then? This has been contributed by members of a company tightly related to Neo4j. MongoDB was not. I expected MongoDB to be supported by the company It brings people to JMeter and Graph a field that is expanding. We try and when something is not successful we drop it, that’s ok for me. > Who will maintain it? We’ll see . I expect initial contributors, I’ll also try to > > > >Possible benefits for users is cleaner UI menus > > What if we add a "import-like" feature to the thread group? > In other words, what if ThreadGroup (or it's ImportConfigurator) includes a > set of checkboxes: > "I want Mongo in this threadgroup" > "I want JSR223 in this threadgroup" > > Then context menus might show only "already imported" elements, to it would > be very small. > "not yet imported" could be either completely hidden, or put into > "unimported yet" sub-menu. > > The user could configure different imports for different thread groups. > Menus are small, and everybody's happy. let’s make a POC of it. But even with it, we should drop MongoDB > > As a bonus, we could even add/remove UI elements from ThreadGroup (or > whatever element) when the set of imports change. > For instance, if the user imports "http testing", then we could show "clear > caches on each iteration" feature to the ThreadGroup / LoopController > configuration. > > mongo-java-driver-2.11.3.jar is 400KiB. > It is 10 times smaller than Saxon-HE-9.9.1-5.jar which is ~5.5M > It is 4 times smaller than commons-math3-3.6.1.jar which is 2.2M > and so on. > > We could try reducing the initial download size by downloading dependencies > from MavenCentral-like repositories, however, that is a different story. > The removal of Mongo does not reduce the download. It’s not about size, it’s about quality and « «uptodateness » And also about number of elements but your proposal would help > > Vladimir >
