On 17 April 2016 at 11:54, Felix Schumacher <[email protected]> wrote: > > > Am 17. April 2016 00:03:34 MESZ, schrieb sebb <[email protected]>: >>On 16 April 2016 at 21:12, Antonio Gomes Rodrigues <[email protected]> >>wrote: >>> Hi, >>> >>> My opinion is that property are not user friendly. >> >>For some items that's true, but for other items having to use the GUI >>is a nuisance. >> >>> This feature must be present in JMeter GUI to be use for the maximum >>of user >> >>I don't think that will work for a a feature that aims to disable what >>the GUI shows; by then it's too late ... > > Eclipse has a feature called "perspectives", where the relevant views for a > task are shown. > > While this might be a number too big for jmeter, we could add an option to > select the current target mode. The avaliable items would be selected > dependent from this target mode. > > This is probably what Philippe wants to add. A property for each mode, that > lists the available items and a way to select the mode in the ui.
That makes more sense. In which case the properties don't belong in jmeter.properties, because they are not something that should normally be adjusted by users. They are really only a way to identify what classes are relevant to each perspective. But I wonder whether they are even needed? In the case of the different sampler types, these are already grouped in different packages and jars. Also there are use cases for including more than one type in a test plan. It's probably more useful to be able to switch off certain types that one knows are not needed. > Regards, > Felix > >> >>> Antonio >>> >>> >>> >>> 2016-04-16 18:07 GMT+02:00 sebb <[email protected]>: >>> >>>> On 16 April 2016 at 13:44, Philippe Mouawad >><[email protected]> >>>> wrote: >>>> > Hello, >>>> > After release of 3.1, I propose to introduce this property: >>>> > ux.test_profile=http,jms,jdbc.... >>>> > ux.profile.http=list of elements related to it >>>> > ux.profile.jms=list of elements related to it >>>> > >>>> > >>>> > This way it would be easy for users by selecting the profile they >>want to >>>> > restrain the number of elements shown to the ones they need . >>>> > >>>> > >>>> > Thoughts ? >>>> >>>> There's already a property which can be used to disable certain >>elements. >>>> >>>> A simpler solution might be to just (re)move the unwanted jars; that >>>> way there is no need even to scan the classes. >>>> >
