2017-10-30 18:07 GMT+01:00 Philippe Mouawad <[email protected]>:
> On Mon, Oct 30, 2017 at 5:10 PM, Emilian Bold <[email protected]> > wrote: > > > 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". > > > Yes go ahead > > > > > > > >>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? > > > > Not that simple, it is more something I see from our work and the answers > we provide on : > > - stackoverflow questions > > > - the user mailing list > > And also https://jmeter-plugins.org/ => Metrics are better IMO since user > see that upgrades exist > > > > > > > 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). > > > Yes > > > > > >>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. > > > > I am not sure. > As you can tell from your own discussion, being late on providing HTTP2 is > not a good point for JMeter and as such for any commercial product relying > on it IMO. > So in a way, providing it as a plugin and not in core is a mistake IMO. > I also find it a bit discouraging as a member of PMC to see so few > contributions from big players, and on that side also I find it's a big > mistake from > commercial project that make money from it not to contribute back to core. > > I still hope this will change. > > Hopefully we have contributions from individuals and it's great. > > > > > > >>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... > > > Yes it was that cause > > > > > > Regarding YaMeter, I think 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. > > > > I'd be happy if you could but anyway good luck with it. > > > > > > 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. > > > True. Your patch improved a lot but still feature is not mature enough yet. > > > > > >>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? > > > I'd love it ! > Is it possible ? > > For me if my remember are good, it's easy And the licence is apache https://github.com/bulenkov/Darcula I can make a try this week > > > >>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). > > > > I don't know about that, what framework would you be using ? What > architecture ? > I think this needs some architectural work to handle Plugins. > How would be provide the 2 UIs together ? > I feel it's a huge piece of work, but I am ready to go for it provided we > have some strong engagement from volunteers for some time. > > On my side priorities are those ones and I would like to complete them > ASAP: > - Completing HTTP Client 4.5 migration, I'm currently working on it > - HTTP2 > > > > > > >>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? > > > > Nothing, if you have a plan, go ahead, I'll be happy to merge PRs. > > > > > >>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). > > > > That's what I feared. > Very bad thinking IMO, we could for example work on more frequent releases > and an improvements of the release process. > > > > > > >>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. > > > > For me it's not a prioritary problem frankly. I see the current > architecture which is simple provides enough power and this is proven by > the number of plugins in the market. > Unless you have a full backward compat solution, I'm for now not convinced > about the benefit vs the sum of problems we'll face. > > > > >>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. > > > > Anything better than RMI :-) > > > > > >>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. > > > > On this side, I am not convinced it should be in Core. But open to ideas. > If we go for providing a Cloud solution, I think JCloud should be used. > I don't want to privilege one Cloud provider unless we have some > involvement from that provider of course. > > > > > --emi > > > > > > -- > Cordialement. > Philippe Mouawad. >
