Answers bellow: >1.1 Metrics >>I believe it is possible to add usage metrics to JMeter while respecting >> the ASF policy on privacy, etc. >>It's also unclear to me how download stats are not shared by the Apache >> mirrors (any ASF document explaining this policy?). >> >I agree with this. > I have asked Apache infra if we are able to get some metrics but it seems > it's not the case. > I am also very unhappy with this and have to default to: > - stackoverflow questions > - downloads of plugins > - user mails
Can I start a discussion with ASF legal@, infra@ and the rest about how an Apache project could get some metrics or add "telemetry". >>2. Speed of development [...] > But another thing, did you have a look at the frequency at which user > upgrade ? Where would I see such info? > I still see a lot of people using version that are 5 year old, so if we > released more often, would user upgrade their versions ? They would, if JMeter would tell them about this and provide a simple one-click way to auto-update (think how Google Chrome autoupdates, etc). >>Are any companies putting resources into JMeter? I see a lot of companies >> / startups trying to make money off JMeter but how many are contributing >> back? >> >Not enough involvement in Core IMO: > - My company Ubik-Ingenierie contributes in 2 ways: > - Patches, bug fixes > - Bigger features like JMeter Web Report , JSON Plugin > - Sponsoring partly my time for working on project > I wonder for example why HTTP2 was not donated immediately to Core. Because it's better for them to control the plugin. >>BTW, one reason I decided to do YaMeter.com instead of trying to push into >> JMeter proper is the approval speed. Getting a patch in seems to take a lot >> of effort and I can only imagine how long it would have take to try >> something as large as what I did with YaMeter. >> >I think we have made improvements in that field, have a look at PR and > Patches taken into account, look at thanks section of every released. > I don't think we are slow to take into account PR provided they are > complete. We give feedback in max 1 days AFAIK. For bugs it is even less. > I don't know statistics of other projects , but from my experience we are > good here. I guess the speed matters less if it's a one-off bugfix that you want to upstream. In my case, I had the time to contribute and felt it would have taken me forever to wait for each fix. Due to bad luck, this also happened near a JMeter release which implied a code freeze of sorts... > Regarding YaMeter, I thing we would have integrated it very quickly. I > wrote to you about it. I have to prepare multiple patches from YaMeter. The code is also using some NetBeans Platform frameworks so I would have to un-tangle those and use simpler things if I have to port it to JMeter as a plugin or something. > Regarding Undo, I was commited after the release, but as you know it is > still not satisfying . Yes, but not because of my patch which fixed quite a few things. >>3. UI > JMeter UI is clearly a bad publicity for the core. I am always disappointed > to read tweet about JMeter looking very 90, being ugly ... > > The IDE is powerful but the Swing look is not great and some LAF are even > more awful , for example the Windows one are very ugly on some OSes. I believe YaMeter looks great and it's just a LnF (Darcula from IntelliJ). How about we add that to JMeter? >>3.1 Swing >>If Swing remains the future of JMeter, I suggest looking into a better >> framework like Apache NetBeans Platform which provides a lot of useful >> things for desktop Java apps. >>Generally speaking, it would be good to split the UI from the "core" so we >> have some path where we evolve to some other UI. >> >If we had time , I would go for a full rewriting either in WEB or Using > Java FX, why not netbeans but I am not an expert of it. I am also very > impressed by IntelliJ look while it is in Swing AFAIK IntelliJ also has the IntelliJ Platform, just like Apache NetBeans Platform. Both are Apache 2.0. >>3.2 Web based >>Alternatively, a web-based interface could be made for JMeter. Any >> interest in this? >> >Yes , but always the same problem , no time This might be an interesting exercise. What sub-set of JMeter could we provide in the 1st release of a web UI? Just some HTTP request and a visualization would be a great start for users (this is where some metrics would help to see what users use most). >>4. Plugin Manager >>It seems unacceptable to me that JMeter does not have a Plugin Manager and >> a plugin portal with some lower-usage plugins (eg. mongodb). >>It's acceptable for other plugins to exist elsewhere, but those should be >> just another "PPA" (see Ubuntu PPA) or another "plugin repository" URL to >> register. >> > >I absolutely agree. When Andrei started his work on Plugin Manager, I wrote > that this feature should have been in JMeter core. How about JMeter provides a Plugin Manager out of the box in the next release? What's so complex about it? >>5.1 HTTP2 >>A major problem being the lack of an official HTTP2 plugin, which people >> have to take from elsewhere. Blazemeter is probably quite happy with their >> implementation being used since it funnels people into their services. >> >Did you get a confirmation from them that they would be ready to donate it ? They don't want to donate it, because it would imply losing control over the plugin and plugin update speed (which with them is a matter of hours while under Apache it would be days). >>7. Module system >>JMeter is using a lot of reflection to reinvent its own quirky module >> system (which provides the way the plugins work). >>This needs some standardization work. >>The NetBeans Platform, for example, comes with its own module system that >> also supports OSGI bundles (another module system). Then, there's the JVM >> service locator (for services) and the Java 9 modules. >> >Probably. OSGI is not a model for me. Too much headache. > JBoss modules was interesting but not enough documented. > Java 9 modules might be a good option. Just too much reflection right now. Standard Java services loader would be a improvement. I have to prepare some patches here too. >>8. Remote is using old technologies >>RMI is a killer in modern setups. It needs open ports on both the slave >> and master for communication which only makes sense within the same >> intranet and it's a pain to configure when using Cloud resources. >>The whole communication between JMeter client and servers should be >> rewritten using more modern protocols. >> >Absolutely, I think the future should be a rest webservice. Not necessarily. But something that requires an open port just on the slave. >>10. Packaging >>JMeter should be everywhere. Official Docker files, AMI images, etc. >> >Not sure, that's a too big scope. Why AMI and not other clouds ? Why docker > and not other technologies ? > I think we need to limit the scope and there is enough communauty to help > here as we already see that. Docker is pretty big. Amazon is pretty big. It doesn't matter which Cloud we target but we have to be more Cloud focused. --emi
