Hi, I've tested it with a ugly POC , wow ! I love it ! Thanks Emilian !!!!!!!
On Mac OSX, it seems to work fine. Do you know what it looks like on Linux and Windows ? In the past I faced issues when plugging existing lafs, mainly "No Copy / Paste". On Mac it seems ok. Regards On Mon, Oct 30, 2017 at 6:13 PM, Antonio Gomes Rodrigues <ra0...@gmail.com> wrote: > 2017-10-30 18:07 GMT+01:00 Philippe Mouawad <philippe.moua...@gmail.com>: > > > On Mon, Oct 30, 2017 at 5:10 PM, Emilian Bold < > emilian.b...@protonmail.ch> > > 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. > > > -- Cordialement. Philippe Mouawad.
