I speak about unknown element. The plugins market needs no discussion, I'm 70% into implementing it.
Andrey Pokhilko On 04/09/2016 11:05 PM, Philippe Mouawad wrote: > On Saturday, April 9, 2016, Andrey Pokhilko <[email protected]> wrote: > >> Accepting bets on the discussion result... I'll better spend the time >> writing code for "plugins market" than to have long discussions. Sorry, >> that's my personal issues. >> >> For me you got the feature idea right, message transferred, so what to >> discuss :)? > are you speaking about the plugin market or unknown element ? > > if first one, what can be discussed is the format and way of working. > If unknown element, then it's true dev can start > >> Andrey Pokhilko >> >> On 04/09/2016 10:21 PM, Philippe Mouawad wrote: >>> what's the problem, let's discuss this in core >>> >>> On Saturday, April 9, 2016, Andrey Pokhilko <[email protected] <javascript:;>> >> wrote: >>>> So you got the idea right. Unfortunately, this can't be done as >>>> third-party plugin, it requires core change. >>>> >>>> Andrey Pokhilko >>>> >>>> On 04/09/2016 10:02 PM, Philippe Mouawad wrote: >>>>> On Saturday, April 9, 2016, Andrey Pokhilko <[email protected] <javascript:;> >> <javascript:;>> >>>> wrote: >>>>>> In fact, I'm already working on "plugins repository" feature. So it >> will >>>>>> be available soon. >>>>>> >>>>>> What could be improved in JMeter regarding situation of unknown plugin >>>>>> in test plan is to still show the test plan, putting some "Unknown >> Class >>>>>> Element" at the place of unknown classes. That would allow reviewing >>>>>> these elements in UI which would be easier than monstrous error >> message >>>>>> currently shown. Although I'd keep the message. Also the plan with >>>>>> "Unknown Element" present wouldn't be available for running. Well, >>>>>> another arguable idea from me, tangential to the subject at hand, so >>>>>> nevermind :). >>>>>> >>>>>> I find this idea interesting. >>>>> The ideal situation for me would be: >>>>> - open the plan >>>>> - Show as you propose unknown element for the missing class with maybe >>>> the >>>>> stacktrace in the gui of this unknown element >>>>> - when saving the plan, the missing class is not changed so the >> initial >>>>> plan is not corrupt >>>>> >>>>> >>>>> >>>>>> Andrey Pokhilko >>>>>> >>>>>> On 04/09/2016 11:56 AM, sebb wrote: >>>>>>> On 8 April 2016 at 22:40, Vladimir Sitnikov < >>>> [email protected] <javascript:;> <javascript:;> >>>>>> <javascript:;>> wrote: >>>>>>>> Philippe> The idea was interesting because it makes things rather >>>>>> simple. >>>>>>>> What if we take a step back and consider some kind of "JMeter Plugin >>>>>> Market"? >>>>>>> This is tangential to the subject at hand. >>>>>>> >>>>>>>> For instance: >>>>>>>> 1) Search & install plugins from within JMeter UI >>>>>>> -1; that would add unnecessary classes to memory. >>>>>>> >>>>>>> However it could be stand-alone. >>>>>>> >>>>>>> Though I'm not sure how much work it would save compared with the >>>>>>> effort of creating and maintaining it. That sounds like a good 3rd >>>>>>> party project; it seems OT for JMeter. >>>>>>> >>>>>>>> 2) If loading a test plan that references not yet installed plugins, >>>>>>>> JMeter would be able to suggest installing the required ones >>>>>>> JMeter only knows what classes the test plan cannot find. >>>>>>> Who is going to maintain the database of plugin locations and their >>>>>> classes? >>>>>>> Who is going to vet the plugins? >>>>>>> >>>>>>> However it might be possible to improve the error messages that are >>>>>>> produced when test classes cannot be found. >>>>>>> >>>>>>>> Vladimir >>
