You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jmeter.apache.org by Philippe Mouawad <p....@ubik-ingenierie.com> on 2018/04/07 07:14:27 UTC

View Results Tree: Drop browser renderer

Hello,
In jdk11, oracle will split javafx and javase.
This component uses javafx, I initially thought it would be a better
renderer but due to security limitations on resources download, it ended up
much less useful and rendering is always partial.

So I propose to drop it in next 4.1 .
Throughts?
Regards


-- 
Cordialement.
Philippe Mouawad.
Ubik-Ingénierie

UBIK LOAD PACK Web Site <http://www.ubikloadpack.com/>

UBIK LOAD PACK on TWITTER <https://twitter.com/ubikloadpack>

Re: View Results Tree: Drop browser renderer

Posted by Jerry Andrews <je...@jrandrews.org>.
JavaFX *is* A thing. I use it regularly. I also use Swing when I have to, as when writing plugins for existing tools (like JMeter and Eclipse).

On 11/8/18, 10:16 AM, "Vladimir Sitnikov" <si...@gmail.com> wrote:

    In the mean time, in the parallel universe they say JavaFX is a thing:
    https://twitter.com/chriswhocodes/status/1060260623601332225
    
    Vladimir
    



Re: View Results Tree: Drop browser renderer

Posted by Felix Schumacher <fe...@internetallee.de>.

Am 8. November 2018 09:51:20 MEZ schrieb Vladimir Sitnikov <si...@gmail.com>:
>In the mean time, in the parallel universe they say JavaFX is a thing:
>https://twitter.com/chriswhocodes/status/1060260623601332225

Have you got it to work with Java 11? I tried, but failed. 

Felix 
>
>Vladimir

Re: View Results Tree: Drop browser renderer

Posted by Vladimir Sitnikov <si...@gmail.com>.
In the mean time, in the parallel universe they say JavaFX is a thing:
https://twitter.com/chriswhocodes/status/1060260623601332225

Vladimir

Re: View Results Tree: Drop browser renderer

Posted by Philippe Mouawad <ph...@gmail.com>.
On Saturday, October 13, 2018, Felix Schumacher <
felix.schumacher@internetallee.de> wrote:

>
>
> Am 13.10.2018 um 10:01 schrieb Philippe Mouawad:
>
>> Hello,
>> Can I drop Browser Renderer for 5.1 version ?
>>
>
> You already have my  +-0 ;)
>
> Would it be better in your opinion, if we hide the exception and print a
> info message, that in order to use the Browser Renderer you would need to
> install JavaFX?


Why not if you find a clean way to do it.

>
> Regards,
>  Felix
>
>>
>> Regards
>>
>> On Fri, Oct 12, 2018 at 10:39 PM Philippe Mouawad <
>> philippe.mouawad@gmail.com> wrote:
>>
>>
>>> On Fri, Oct 12, 2018 at 10:35 PM Felix Schumacher <
>>> felix.schumacher@internetallee.de> wrote:
>>>
>>>
>>>> Am 12.10.2018 um 22:30 schrieb Philippe Mouawad:
>>>>
>>>>> My 2 cents below.
>>>>>
>>>>> Regards
>>>>>
>>>>> On Fri, Oct 12, 2018 at 10:15 PM Felix Schumacher <
>>>>> felix.schumacher@internetallee.de> wrote:
>>>>>
>>>>> Am 12.10.2018 um 21:44 schrieb Philippe Mouawad:
>>>>>>
>>>>>>> Hello Felix,
>>>>>>>
>>>>>>> Thanks for your feedback.
>>>>>>> Regarding the place where to put them, frankly I don't know.
>>>>>>> Andrei proposed to make them available in jmeter-plugins plugins
>>>>>>>
>>>>>> manager
>>>>
>>>>> but required that we do the move to some github repo and contribute a
>>>>>>> plugin descriptor.
>>>>>>> I must say that for now, I feel it's too much work for me , which I
>>>>>>>
>>>>>> prefer
>>>>>>
>>>>>>> to invest on useful features.
>>>>>>>
>>>>>>> Should we create a github jmeter-legacy-plugins project ?
>>>>>>>
>>>>>> Would it be enough to create a new branch in our svn repository? That
>>>>>> should be mirrored automatically to github.
>>>>>>
>>>>>> I think it would be better to create a new github project
>>>>>
>>>>> What would be the plan for releasing those plugins?
>>>>>>
>>>>>> Move them to this repo
>>>>> Create a plugin descriptor
>>>>> Then they will live their end of life
>>>>>
>>>>> If we donate them to someone outside of Apache, would we have to rename
>>>>>> the packages and would old test plans still work?
>>>>>>
>>>>>> I think we need to keep package name to avoid breaking existing plans.
>>>>>
>>>> Well I believe my real question was, would the code stay inside the
>>>> Apache JMeter project, or completely in the wild?
>>>> I am not sure, that it would be a good idea to leave the namespace
>>>> unchanged, when we release them into the non-apache-world.
>>>>
>>>> My idea was to drop them from repo.
>>> If we don't keep the name, we break plans.
>>> If we keep them, do you think it's a blocker for releasing them into the
>>> non-apache-world, even if we name the repository
>>> apache-jmeter-legacy-plugins ?
>>>
>>> If we need to keep them in JMeter repository, I don't see the gain as
>>> there will be work to maintain this.
>>>
>>>
>>> Felix
>>>>
>>>>> Scratching my head.
>>>>>>     Felix
>>>>>>
>>>>>> Regards
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Oct 12, 2018 at 9:39 PM Felix Schumacher <
>>>>>>> felix.schumacher@internetallee.de> wrote:
>>>>>>>
>>>>>>> Am 12. Oktober 2018 20:43:50 MESZ schrieb Philippe Mouawad <
>>>>>>>> p.mouawad@ubik-ingenierie.com>:
>>>>>>>>
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> Do we have a consensus on dropping RenderInBrowser ?
>>>>>>>>>
>>>>>>>> I like it, as it gives a nicer rendering than the really old java
>>>>>>>> component, but have to admit that JavaFX is going to be a lot harder
>>>>>>>>
>>>>>>> to
>>>>
>>>>> find in the default installation. And my pages are probably not the
>>>>>>>>
>>>>>>> most
>>>>
>>>>> complex ones, so there are no problems from missing resources.
>>>>>>>>
>>>>>>>> Has anyone has tried to get JavaFX as an Extremfall dependency into
>>>>>>>>
>>>>>>> the
>>>>
>>>>> build process?
>>>>>>>>
>>>>>>>> All in all I am +-0 to kick it out.
>>>>>>>>
>>>>>>>> Do we have a place for those old 'plugins'? That would be useful for
>>>>>>>>
>>>>>>> the
>>>>
>>>>> mongodb plugin, too.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>     Felix
>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>> Regards
>>>>>>>>>
>>>>>>>>> On Fri, Oct 12, 2018 at 8:43 PM UBIK LOAD PACK Support <
>>>>>>>>> support@ubikloadpack.com> wrote:
>>>>>>>>>
>>>>>>>>> For information, as I think message was for mailing list.
>>>>>>>>>>
>>>>>>>>>> Regards
>>>>>>>>>>
>>>>>>>>>> ---------- Forwarded message ---------
>>>>>>>>>> From: Milamber <mi...@apache.org>
>>>>>>>>>> Date: Fri, Oct 5, 2018 at 8:19 AM
>>>>>>>>>> Subject: Re: View Results Tree: Drop browser renderer
>>>>>>>>>> To: UBIK LOAD PACK Support <su...@ubikloadpack.com>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Hello,
>>>>>>>>>>
>>>>>>>>>> I'm agree to suppress this renderer. It's not very useful, bad
>>>>>>>>>>
>>>>>>>>> rendering
>>>>>>>>>
>>>>>>>>>> and too slow.
>>>>>>>>>>
>>>>>>>>>> Milamber
>>>>>>>>>>
>>>>>>>>>> On 26/09/2018 08:55, UBIK LOAD PACK Support wrote:
>>>>>>>>>>
>>>>>>>>>>> Hello,
>>>>>>>>>>> Isn't it time to drop Browser component and dependency on Java FX
>>>>>>>>>>>
>>>>>>>>>> in next
>>>>>>>>>
>>>>>>>>>> version ?:
>>>>>>>>>>>
>>>>>>>>>>>        - It is not available in OpenJDK which should become the
>>>>>>>>>>>
>>>>>>>>>> most
>>>>
>>>>> used
>>>>>>>>>
>>>>>>>>>> JVM ?
>>>>>>>>>>
>>>>>>>>>>>        It currently trigger an ugly stacktrace
>>>>>>>>>>>        - It introduces complexity and did not offer that much
>>>>>>>>>>>
>>>>>>>>>> interest
>>>>
>>>>> as
>>>>>>>>>
>>>>>>>>>>        initially expected
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Regards
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Apr 12, 2018 at 8:10 PM Felix Schumacher <
>>>>>>>>>>> felix.schumacher@internetallee.de> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Am 07.04.2018 um 09:14 schrieb Philippe Mouawad:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>> In jdk11, oracle will split javafx and javase.
>>>>>>>>>>>>> This component uses javafx, I initially thought it would be a
>>>>>>>>>>>>>
>>>>>>>>>>>> better
>>>>>>>>>
>>>>>>>>>> renderer but due to security limitations on resources download,
>>>>>>>>>>>>>
>>>>>>>>>>>> it
>>>>>>>>>
>>>>>>>>>> ended
>>>>>>>>>>
>>>>>>>>>>> up
>>>>>>>>>>>>
>>>>>>>>>>>>> much less useful and rendering is always partial.
>>>>>>>>>>>>>
>>>>>>>>>>>>> So I propose to drop it in next 4.1 .
>>>>>>>>>>>>>
>>>>>>>>>>>> Is there any chance to bypass the limitations on resource
>>>>>>>>>>>>
>>>>>>>>>>> download? I
>>>>>>>>>
>>>>>>>>>> found the rendering to be a bit better than the built-in
>>>>>>>>>>>>
>>>>>>>>>>> "browser", but
>>>>>>>>>
>>>>>>>>>> there is certainly a lot of room for improvement.
>>>>>>>>>>>>
>>>>>>>>>>>> Felix
>>>>>>>>>>>>
>>>>>>>>>>>> Throughts?
>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>
>>>>>>>>>> Regards
>>>>>>>>>> Ubik Load Pack <http://ubikloadpack.com> Team
>>>>>>>>>> Follow us on Twitter <http://twitter.com/ubikloadpack>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Cordialement
>>>>>>>>>> L'équipe Ubik Load Pack <http://ubikloadpack.com>
>>>>>>>>>> Suivez-nous sur Twitter <http://twitter.com/ubikloadpack>
>>>>>>>>>>
>>>>>>>>>>
>>>> --
>>> Cordialement.
>>> Philippe Mouawad.
>>>
>>>
>>>
>>>
>

-- 
Cordialement.
Philippe Mouawad.

Re: View Results Tree: Drop browser renderer

Posted by Felix Schumacher <fe...@internetallee.de>.

Am 13.10.2018 um 10:01 schrieb Philippe Mouawad:
> Hello,
> Can I drop Browser Renderer for 5.1 version ?

You already have my  +-0 ;)

Would it be better in your opinion, if we hide the exception and print a 
info message, that in order to use the Browser Renderer you would need 
to install JavaFX?

Regards,
  Felix
>
> Regards
>
> On Fri, Oct 12, 2018 at 10:39 PM Philippe Mouawad <
> philippe.mouawad@gmail.com> wrote:
>
>>
>> On Fri, Oct 12, 2018 at 10:35 PM Felix Schumacher <
>> felix.schumacher@internetallee.de> wrote:
>>
>>>
>>> Am 12.10.2018 um 22:30 schrieb Philippe Mouawad:
>>>> My 2 cents below.
>>>>
>>>> Regards
>>>>
>>>> On Fri, Oct 12, 2018 at 10:15 PM Felix Schumacher <
>>>> felix.schumacher@internetallee.de> wrote:
>>>>
>>>>> Am 12.10.2018 um 21:44 schrieb Philippe Mouawad:
>>>>>> Hello Felix,
>>>>>>
>>>>>> Thanks for your feedback.
>>>>>> Regarding the place where to put them, frankly I don't know.
>>>>>> Andrei proposed to make them available in jmeter-plugins plugins
>>> manager
>>>>>> but required that we do the move to some github repo and contribute a
>>>>>> plugin descriptor.
>>>>>> I must say that for now, I feel it's too much work for me , which I
>>>>> prefer
>>>>>> to invest on useful features.
>>>>>>
>>>>>> Should we create a github jmeter-legacy-plugins project ?
>>>>> Would it be enough to create a new branch in our svn repository? That
>>>>> should be mirrored automatically to github.
>>>>>
>>>> I think it would be better to create a new github project
>>>>
>>>>> What would be the plan for releasing those plugins?
>>>>>
>>>> Move them to this repo
>>>> Create a plugin descriptor
>>>> Then they will live their end of life
>>>>
>>>>> If we donate them to someone outside of Apache, would we have to rename
>>>>> the packages and would old test plans still work?
>>>>>
>>>> I think we need to keep package name to avoid breaking existing plans.
>>> Well I believe my real question was, would the code stay inside the
>>> Apache JMeter project, or completely in the wild?
>>> I am not sure, that it would be a good idea to leave the namespace
>>> unchanged, when we release them into the non-apache-world.
>>>
>> My idea was to drop them from repo.
>> If we don't keep the name, we break plans.
>> If we keep them, do you think it's a blocker for releasing them into the
>> non-apache-world, even if we name the repository
>> apache-jmeter-legacy-plugins ?
>>
>> If we need to keep them in JMeter repository, I don't see the gain as
>> there will be work to maintain this.
>>
>>
>>> Felix
>>>>> Scratching my head.
>>>>>     Felix
>>>>>
>>>>>> Regards
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Oct 12, 2018 at 9:39 PM Felix Schumacher <
>>>>>> felix.schumacher@internetallee.de> wrote:
>>>>>>
>>>>>>> Am 12. Oktober 2018 20:43:50 MESZ schrieb Philippe Mouawad <
>>>>>>> p.mouawad@ubik-ingenierie.com>:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> Do we have a consensus on dropping RenderInBrowser ?
>>>>>>> I like it, as it gives a nicer rendering than the really old java
>>>>>>> component, but have to admit that JavaFX is going to be a lot harder
>>> to
>>>>>>> find in the default installation. And my pages are probably not the
>>> most
>>>>>>> complex ones, so there are no problems from missing resources.
>>>>>>>
>>>>>>> Has anyone has tried to get JavaFX as an Extremfall dependency into
>>> the
>>>>>>> build process?
>>>>>>>
>>>>>>> All in all I am +-0 to kick it out.
>>>>>>>
>>>>>>> Do we have a place for those old 'plugins'? That would be useful for
>>> the
>>>>>>> mongodb plugin, too.
>>>>>>>
>>>>>>> Regards,
>>>>>>>     Felix
>>>>>>>> Thanks
>>>>>>>> Regards
>>>>>>>>
>>>>>>>> On Fri, Oct 12, 2018 at 8:43 PM UBIK LOAD PACK Support <
>>>>>>>> support@ubikloadpack.com> wrote:
>>>>>>>>
>>>>>>>>> For information, as I think message was for mailing list.
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>>
>>>>>>>>> ---------- Forwarded message ---------
>>>>>>>>> From: Milamber <mi...@apache.org>
>>>>>>>>> Date: Fri, Oct 5, 2018 at 8:19 AM
>>>>>>>>> Subject: Re: View Results Tree: Drop browser renderer
>>>>>>>>> To: UBIK LOAD PACK Support <su...@ubikloadpack.com>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> I'm agree to suppress this renderer. It's not very useful, bad
>>>>>>>> rendering
>>>>>>>>> and too slow.
>>>>>>>>>
>>>>>>>>> Milamber
>>>>>>>>>
>>>>>>>>> On 26/09/2018 08:55, UBIK LOAD PACK Support wrote:
>>>>>>>>>> Hello,
>>>>>>>>>> Isn't it time to drop Browser component and dependency on Java FX
>>>>>>>> in next
>>>>>>>>>> version ?:
>>>>>>>>>>
>>>>>>>>>>        - It is not available in OpenJDK which should become the
>>> most
>>>>>>>> used
>>>>>>>>> JVM ?
>>>>>>>>>>        It currently trigger an ugly stacktrace
>>>>>>>>>>        - It introduces complexity and did not offer that much
>>> interest
>>>>>>>> as
>>>>>>>>>>        initially expected
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Regards
>>>>>>>>>>
>>>>>>>>>> On Thu, Apr 12, 2018 at 8:10 PM Felix Schumacher <
>>>>>>>>>> felix.schumacher@internetallee.de> wrote:
>>>>>>>>>>
>>>>>>>>>>> Am 07.04.2018 um 09:14 schrieb Philippe Mouawad:
>>>>>>>>>>>> Hello,
>>>>>>>>>>>> In jdk11, oracle will split javafx and javase.
>>>>>>>>>>>> This component uses javafx, I initially thought it would be a
>>>>>>>> better
>>>>>>>>>>>> renderer but due to security limitations on resources download,
>>>>>>>> it
>>>>>>>>> ended
>>>>>>>>>>> up
>>>>>>>>>>>> much less useful and rendering is always partial.
>>>>>>>>>>>>
>>>>>>>>>>>> So I propose to drop it in next 4.1 .
>>>>>>>>>>> Is there any chance to bypass the limitations on resource
>>>>>>>> download? I
>>>>>>>>>>> found the rendering to be a bit better than the built-in
>>>>>>>> "browser", but
>>>>>>>>>>> there is certainly a lot of room for improvement.
>>>>>>>>>>>
>>>>>>>>>>> Felix
>>>>>>>>>>>
>>>>>>>>>>>> Throughts?
>>>>>>>>>>>> Regards
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>> --
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>> Ubik Load Pack <http://ubikloadpack.com> Team
>>>>>>>>> Follow us on Twitter <http://twitter.com/ubikloadpack>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Cordialement
>>>>>>>>> L'équipe Ubik Load Pack <http://ubikloadpack.com>
>>>>>>>>> Suivez-nous sur Twitter <http://twitter.com/ubikloadpack>
>>>>>>>>>
>>>
>> --
>> Cordialement.
>> Philippe Mouawad.
>>
>>
>>


Re: View Results Tree: Drop browser renderer

Posted by Philippe Mouawad <ph...@gmail.com>.
Hello,
Can I drop Browser Renderer for 5.1 version ?

Regards

On Fri, Oct 12, 2018 at 10:39 PM Philippe Mouawad <
philippe.mouawad@gmail.com> wrote:

>
>
> On Fri, Oct 12, 2018 at 10:35 PM Felix Schumacher <
> felix.schumacher@internetallee.de> wrote:
>
>>
>>
>> Am 12.10.2018 um 22:30 schrieb Philippe Mouawad:
>> > My 2 cents below.
>> >
>> > Regards
>> >
>> > On Fri, Oct 12, 2018 at 10:15 PM Felix Schumacher <
>> > felix.schumacher@internetallee.de> wrote:
>> >
>> >>
>> >> Am 12.10.2018 um 21:44 schrieb Philippe Mouawad:
>> >>> Hello Felix,
>> >>>
>> >>> Thanks for your feedback.
>> >>> Regarding the place where to put them, frankly I don't know.
>> >>> Andrei proposed to make them available in jmeter-plugins plugins
>> manager
>> >>> but required that we do the move to some github repo and contribute a
>> >>> plugin descriptor.
>> >>> I must say that for now, I feel it's too much work for me , which I
>> >> prefer
>> >>> to invest on useful features.
>> >>>
>> >>> Should we create a github jmeter-legacy-plugins project ?
>> >> Would it be enough to create a new branch in our svn repository? That
>> >> should be mirrored automatically to github.
>> >>
>> > I think it would be better to create a new github project
>> >
>> >> What would be the plan for releasing those plugins?
>> >>
>> > Move them to this repo
>> > Create a plugin descriptor
>> > Then they will live their end of life
>> >
>> >> If we donate them to someone outside of Apache, would we have to rename
>> >> the packages and would old test plans still work?
>> >>
>> > I think we need to keep package name to avoid breaking existing plans.
>>
>> Well I believe my real question was, would the code stay inside the
>> Apache JMeter project, or completely in the wild?
>> I am not sure, that it would be a good idea to leave the namespace
>> unchanged, when we release them into the non-apache-world.
>>
>
> My idea was to drop them from repo.
> If we don't keep the name, we break plans.
> If we keep them, do you think it's a blocker for releasing them into the
> non-apache-world, even if we name the repository
> apache-jmeter-legacy-plugins ?
>
> If we need to keep them in JMeter repository, I don't see the gain as
> there will be work to maintain this.
>
>
>> Felix
>> >
>> >> Scratching my head.
>> >>    Felix
>> >>
>> >>> Regards
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> On Fri, Oct 12, 2018 at 9:39 PM Felix Schumacher <
>> >>> felix.schumacher@internetallee.de> wrote:
>> >>>
>> >>>> Am 12. Oktober 2018 20:43:50 MESZ schrieb Philippe Mouawad <
>> >>>> p.mouawad@ubik-ingenierie.com>:
>> >>>>> Hello,
>> >>>>>
>> >>>>> Do we have a consensus on dropping RenderInBrowser ?
>> >>>> I like it, as it gives a nicer rendering than the really old java
>> >>>> component, but have to admit that JavaFX is going to be a lot harder
>> to
>> >>>> find in the default installation. And my pages are probably not the
>> most
>> >>>> complex ones, so there are no problems from missing resources.
>> >>>>
>> >>>> Has anyone has tried to get JavaFX as an Extremfall dependency into
>> the
>> >>>> build process?
>> >>>>
>> >>>> All in all I am +-0 to kick it out.
>> >>>>
>> >>>> Do we have a place for those old 'plugins'? That would be useful for
>> the
>> >>>> mongodb plugin, too.
>> >>>>
>> >>>> Regards,
>> >>>>    Felix
>> >>>>> Thanks
>> >>>>> Regards
>> >>>>>
>> >>>>> On Fri, Oct 12, 2018 at 8:43 PM UBIK LOAD PACK Support <
>> >>>>> support@ubikloadpack.com> wrote:
>> >>>>>
>> >>>>>> For information, as I think message was for mailing list.
>> >>>>>>
>> >>>>>> Regards
>> >>>>>>
>> >>>>>> ---------- Forwarded message ---------
>> >>>>>> From: Milamber <mi...@apache.org>
>> >>>>>> Date: Fri, Oct 5, 2018 at 8:19 AM
>> >>>>>> Subject: Re: View Results Tree: Drop browser renderer
>> >>>>>> To: UBIK LOAD PACK Support <su...@ubikloadpack.com>
>> >>>>>>
>> >>>>>>
>> >>>>>> Hello,
>> >>>>>>
>> >>>>>> I'm agree to suppress this renderer. It's not very useful, bad
>> >>>>> rendering
>> >>>>>> and too slow.
>> >>>>>>
>> >>>>>> Milamber
>> >>>>>>
>> >>>>>> On 26/09/2018 08:55, UBIK LOAD PACK Support wrote:
>> >>>>>>> Hello,
>> >>>>>>> Isn't it time to drop Browser component and dependency on Java FX
>> >>>>> in next
>> >>>>>>> version ?:
>> >>>>>>>
>> >>>>>>>       - It is not available in OpenJDK which should become the
>> most
>> >>>>> used
>> >>>>>> JVM ?
>> >>>>>>>       It currently trigger an ugly stacktrace
>> >>>>>>>       - It introduces complexity and did not offer that much
>> interest
>> >>>>> as
>> >>>>>>>       initially expected
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> Regards
>> >>>>>>>
>> >>>>>>> On Thu, Apr 12, 2018 at 8:10 PM Felix Schumacher <
>> >>>>>>> felix.schumacher@internetallee.de> wrote:
>> >>>>>>>
>> >>>>>>>> Am 07.04.2018 um 09:14 schrieb Philippe Mouawad:
>> >>>>>>>>> Hello,
>> >>>>>>>>> In jdk11, oracle will split javafx and javase.
>> >>>>>>>>> This component uses javafx, I initially thought it would be a
>> >>>>> better
>> >>>>>>>>> renderer but due to security limitations on resources download,
>> >>>>> it
>> >>>>>> ended
>> >>>>>>>> up
>> >>>>>>>>> much less useful and rendering is always partial.
>> >>>>>>>>>
>> >>>>>>>>> So I propose to drop it in next 4.1 .
>> >>>>>>>> Is there any chance to bypass the limitations on resource
>> >>>>> download? I
>> >>>>>>>> found the rendering to be a bit better than the built-in
>> >>>>> "browser", but
>> >>>>>>>> there is certainly a lot of room for improvement.
>> >>>>>>>>
>> >>>>>>>> Felix
>> >>>>>>>>
>> >>>>>>>>> Throughts?
>> >>>>>>>>> Regards
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>
>> >>>>>> --
>> >>>>>>
>> >>>>>> Regards
>> >>>>>> Ubik Load Pack <http://ubikloadpack.com> Team
>> >>>>>> Follow us on Twitter <http://twitter.com/ubikloadpack>
>> >>>>>>
>> >>>>>>
>> >>>>>> Cordialement
>> >>>>>> L'équipe Ubik Load Pack <http://ubikloadpack.com>
>> >>>>>> Suivez-nous sur Twitter <http://twitter.com/ubikloadpack>
>> >>>>>>
>> >>
>>
>>
>
> --
> Cordialement.
> Philippe Mouawad.
>
>
>

-- 
Cordialement.
Philippe Mouawad.

Re: View Results Tree: Drop browser renderer

Posted by Philippe Mouawad <ph...@gmail.com>.
On Fri, Oct 12, 2018 at 10:35 PM Felix Schumacher <
felix.schumacher@internetallee.de> wrote:

>
>
> Am 12.10.2018 um 22:30 schrieb Philippe Mouawad:
> > My 2 cents below.
> >
> > Regards
> >
> > On Fri, Oct 12, 2018 at 10:15 PM Felix Schumacher <
> > felix.schumacher@internetallee.de> wrote:
> >
> >>
> >> Am 12.10.2018 um 21:44 schrieb Philippe Mouawad:
> >>> Hello Felix,
> >>>
> >>> Thanks for your feedback.
> >>> Regarding the place where to put them, frankly I don't know.
> >>> Andrei proposed to make them available in jmeter-plugins plugins
> manager
> >>> but required that we do the move to some github repo and contribute a
> >>> plugin descriptor.
> >>> I must say that for now, I feel it's too much work for me , which I
> >> prefer
> >>> to invest on useful features.
> >>>
> >>> Should we create a github jmeter-legacy-plugins project ?
> >> Would it be enough to create a new branch in our svn repository? That
> >> should be mirrored automatically to github.
> >>
> > I think it would be better to create a new github project
> >
> >> What would be the plan for releasing those plugins?
> >>
> > Move them to this repo
> > Create a plugin descriptor
> > Then they will live their end of life
> >
> >> If we donate them to someone outside of Apache, would we have to rename
> >> the packages and would old test plans still work?
> >>
> > I think we need to keep package name to avoid breaking existing plans.
>
> Well I believe my real question was, would the code stay inside the
> Apache JMeter project, or completely in the wild?
> I am not sure, that it would be a good idea to leave the namespace
> unchanged, when we release them into the non-apache-world.
>

My idea was to drop them from repo.
If we don't keep the name, we break plans.
If we keep them, do you think it's a blocker for releasing them into the
non-apache-world, even if we name the repository
apache-jmeter-legacy-plugins ?

If we need to keep them in JMeter repository, I don't see the gain as there
will be work to maintain this.


> Felix
> >
> >> Scratching my head.
> >>    Felix
> >>
> >>> Regards
> >>>
> >>>
> >>>
> >>>
> >>> On Fri, Oct 12, 2018 at 9:39 PM Felix Schumacher <
> >>> felix.schumacher@internetallee.de> wrote:
> >>>
> >>>> Am 12. Oktober 2018 20:43:50 MESZ schrieb Philippe Mouawad <
> >>>> p.mouawad@ubik-ingenierie.com>:
> >>>>> Hello,
> >>>>>
> >>>>> Do we have a consensus on dropping RenderInBrowser ?
> >>>> I like it, as it gives a nicer rendering than the really old java
> >>>> component, but have to admit that JavaFX is going to be a lot harder
> to
> >>>> find in the default installation. And my pages are probably not the
> most
> >>>> complex ones, so there are no problems from missing resources.
> >>>>
> >>>> Has anyone has tried to get JavaFX as an Extremfall dependency into
> the
> >>>> build process?
> >>>>
> >>>> All in all I am +-0 to kick it out.
> >>>>
> >>>> Do we have a place for those old 'plugins'? That would be useful for
> the
> >>>> mongodb plugin, too.
> >>>>
> >>>> Regards,
> >>>>    Felix
> >>>>> Thanks
> >>>>> Regards
> >>>>>
> >>>>> On Fri, Oct 12, 2018 at 8:43 PM UBIK LOAD PACK Support <
> >>>>> support@ubikloadpack.com> wrote:
> >>>>>
> >>>>>> For information, as I think message was for mailing list.
> >>>>>>
> >>>>>> Regards
> >>>>>>
> >>>>>> ---------- Forwarded message ---------
> >>>>>> From: Milamber <mi...@apache.org>
> >>>>>> Date: Fri, Oct 5, 2018 at 8:19 AM
> >>>>>> Subject: Re: View Results Tree: Drop browser renderer
> >>>>>> To: UBIK LOAD PACK Support <su...@ubikloadpack.com>
> >>>>>>
> >>>>>>
> >>>>>> Hello,
> >>>>>>
> >>>>>> I'm agree to suppress this renderer. It's not very useful, bad
> >>>>> rendering
> >>>>>> and too slow.
> >>>>>>
> >>>>>> Milamber
> >>>>>>
> >>>>>> On 26/09/2018 08:55, UBIK LOAD PACK Support wrote:
> >>>>>>> Hello,
> >>>>>>> Isn't it time to drop Browser component and dependency on Java FX
> >>>>> in next
> >>>>>>> version ?:
> >>>>>>>
> >>>>>>>       - It is not available in OpenJDK which should become the most
> >>>>> used
> >>>>>> JVM ?
> >>>>>>>       It currently trigger an ugly stacktrace
> >>>>>>>       - It introduces complexity and did not offer that much
> interest
> >>>>> as
> >>>>>>>       initially expected
> >>>>>>>
> >>>>>>>
> >>>>>>> Regards
> >>>>>>>
> >>>>>>> On Thu, Apr 12, 2018 at 8:10 PM Felix Schumacher <
> >>>>>>> felix.schumacher@internetallee.de> wrote:
> >>>>>>>
> >>>>>>>> Am 07.04.2018 um 09:14 schrieb Philippe Mouawad:
> >>>>>>>>> Hello,
> >>>>>>>>> In jdk11, oracle will split javafx and javase.
> >>>>>>>>> This component uses javafx, I initially thought it would be a
> >>>>> better
> >>>>>>>>> renderer but due to security limitations on resources download,
> >>>>> it
> >>>>>> ended
> >>>>>>>> up
> >>>>>>>>> much less useful and rendering is always partial.
> >>>>>>>>>
> >>>>>>>>> So I propose to drop it in next 4.1 .
> >>>>>>>> Is there any chance to bypass the limitations on resource
> >>>>> download? I
> >>>>>>>> found the rendering to be a bit better than the built-in
> >>>>> "browser", but
> >>>>>>>> there is certainly a lot of room for improvement.
> >>>>>>>>
> >>>>>>>> Felix
> >>>>>>>>
> >>>>>>>>> Throughts?
> >>>>>>>>> Regards
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>
> >>>>>> --
> >>>>>>
> >>>>>> Regards
> >>>>>> Ubik Load Pack <http://ubikloadpack.com> Team
> >>>>>> Follow us on Twitter <http://twitter.com/ubikloadpack>
> >>>>>>
> >>>>>>
> >>>>>> Cordialement
> >>>>>> L'équipe Ubik Load Pack <http://ubikloadpack.com>
> >>>>>> Suivez-nous sur Twitter <http://twitter.com/ubikloadpack>
> >>>>>>
> >>
>
>

-- 
Cordialement.
Philippe Mouawad.

Re: View Results Tree: Drop browser renderer

Posted by Felix Schumacher <fe...@internetallee.de>.

Am 12.10.2018 um 22:30 schrieb Philippe Mouawad:
> My 2 cents below.
>
> Regards
>
> On Fri, Oct 12, 2018 at 10:15 PM Felix Schumacher <
> felix.schumacher@internetallee.de> wrote:
>
>>
>> Am 12.10.2018 um 21:44 schrieb Philippe Mouawad:
>>> Hello Felix,
>>>
>>> Thanks for your feedback.
>>> Regarding the place where to put them, frankly I don't know.
>>> Andrei proposed to make them available in jmeter-plugins plugins manager
>>> but required that we do the move to some github repo and contribute a
>>> plugin descriptor.
>>> I must say that for now, I feel it's too much work for me , which I
>> prefer
>>> to invest on useful features.
>>>
>>> Should we create a github jmeter-legacy-plugins project ?
>> Would it be enough to create a new branch in our svn repository? That
>> should be mirrored automatically to github.
>>
> I think it would be better to create a new github project
>
>> What would be the plan for releasing those plugins?
>>
> Move them to this repo
> Create a plugin descriptor
> Then they will live their end of life
>
>> If we donate them to someone outside of Apache, would we have to rename
>> the packages and would old test plans still work?
>>
> I think we need to keep package name to avoid breaking existing plans.

Well I believe my real question was, would the code stay inside the 
Apache JMeter project, or completely in the wild?
I am not sure, that it would be a good idea to leave the namespace 
unchanged, when we release them into the non-apache-world.

Felix
>
>> Scratching my head.
>>    Felix
>>
>>> Regards
>>>
>>>
>>>
>>>
>>> On Fri, Oct 12, 2018 at 9:39 PM Felix Schumacher <
>>> felix.schumacher@internetallee.de> wrote:
>>>
>>>> Am 12. Oktober 2018 20:43:50 MESZ schrieb Philippe Mouawad <
>>>> p.mouawad@ubik-ingenierie.com>:
>>>>> Hello,
>>>>>
>>>>> Do we have a consensus on dropping RenderInBrowser ?
>>>> I like it, as it gives a nicer rendering than the really old java
>>>> component, but have to admit that JavaFX is going to be a lot harder to
>>>> find in the default installation. And my pages are probably not the most
>>>> complex ones, so there are no problems from missing resources.
>>>>
>>>> Has anyone has tried to get JavaFX as an Extremfall dependency into the
>>>> build process?
>>>>
>>>> All in all I am +-0 to kick it out.
>>>>
>>>> Do we have a place for those old 'plugins'? That would be useful for the
>>>> mongodb plugin, too.
>>>>
>>>> Regards,
>>>>    Felix
>>>>> Thanks
>>>>> Regards
>>>>>
>>>>> On Fri, Oct 12, 2018 at 8:43 PM UBIK LOAD PACK Support <
>>>>> support@ubikloadpack.com> wrote:
>>>>>
>>>>>> For information, as I think message was for mailing list.
>>>>>>
>>>>>> Regards
>>>>>>
>>>>>> ---------- Forwarded message ---------
>>>>>> From: Milamber <mi...@apache.org>
>>>>>> Date: Fri, Oct 5, 2018 at 8:19 AM
>>>>>> Subject: Re: View Results Tree: Drop browser renderer
>>>>>> To: UBIK LOAD PACK Support <su...@ubikloadpack.com>
>>>>>>
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> I'm agree to suppress this renderer. It's not very useful, bad
>>>>> rendering
>>>>>> and too slow.
>>>>>>
>>>>>> Milamber
>>>>>>
>>>>>> On 26/09/2018 08:55, UBIK LOAD PACK Support wrote:
>>>>>>> Hello,
>>>>>>> Isn't it time to drop Browser component and dependency on Java FX
>>>>> in next
>>>>>>> version ?:
>>>>>>>
>>>>>>>       - It is not available in OpenJDK which should become the most
>>>>> used
>>>>>> JVM ?
>>>>>>>       It currently trigger an ugly stacktrace
>>>>>>>       - It introduces complexity and did not offer that much interest
>>>>> as
>>>>>>>       initially expected
>>>>>>>
>>>>>>>
>>>>>>> Regards
>>>>>>>
>>>>>>> On Thu, Apr 12, 2018 at 8:10 PM Felix Schumacher <
>>>>>>> felix.schumacher@internetallee.de> wrote:
>>>>>>>
>>>>>>>> Am 07.04.2018 um 09:14 schrieb Philippe Mouawad:
>>>>>>>>> Hello,
>>>>>>>>> In jdk11, oracle will split javafx and javase.
>>>>>>>>> This component uses javafx, I initially thought it would be a
>>>>> better
>>>>>>>>> renderer but due to security limitations on resources download,
>>>>> it
>>>>>> ended
>>>>>>>> up
>>>>>>>>> much less useful and rendering is always partial.
>>>>>>>>>
>>>>>>>>> So I propose to drop it in next 4.1 .
>>>>>>>> Is there any chance to bypass the limitations on resource
>>>>> download? I
>>>>>>>> found the rendering to be a bit better than the built-in
>>>>> "browser", but
>>>>>>>> there is certainly a lot of room for improvement.
>>>>>>>>
>>>>>>>> Felix
>>>>>>>>
>>>>>>>>> Throughts?
>>>>>>>>> Regards
>>>>>>>>>
>>>>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> Regards
>>>>>> Ubik Load Pack <http://ubikloadpack.com> Team
>>>>>> Follow us on Twitter <http://twitter.com/ubikloadpack>
>>>>>>
>>>>>>
>>>>>> Cordialement
>>>>>> L'équipe Ubik Load Pack <http://ubikloadpack.com>
>>>>>> Suivez-nous sur Twitter <http://twitter.com/ubikloadpack>
>>>>>>
>>


Re: View Results Tree: Drop browser renderer

Posted by Philippe Mouawad <ph...@gmail.com>.
My 2 cents below.

Regards

On Fri, Oct 12, 2018 at 10:15 PM Felix Schumacher <
felix.schumacher@internetallee.de> wrote:

>
>
> Am 12.10.2018 um 21:44 schrieb Philippe Mouawad:
> > Hello Felix,
> >
> > Thanks for your feedback.
> > Regarding the place where to put them, frankly I don't know.
> > Andrei proposed to make them available in jmeter-plugins plugins manager
> > but required that we do the move to some github repo and contribute a
> > plugin descriptor.
> > I must say that for now, I feel it's too much work for me , which I
> prefer
> > to invest on useful features.
> >
> > Should we create a github jmeter-legacy-plugins project ?
> Would it be enough to create a new branch in our svn repository? That
> should be mirrored automatically to github.
>

I think it would be better to create a new github project

>
> What would be the plan for releasing those plugins?
>

Move them to this repo
Create a plugin descriptor
Then they will live their end of life

>
> If we donate them to someone outside of Apache, would we have to rename
> the packages and would old test plans still work?
>

I think we need to keep package name to avoid breaking existing plans.

>
> Scratching my head.
>   Felix
>
> >
> > Regards
> >
> >
> >
> >
> > On Fri, Oct 12, 2018 at 9:39 PM Felix Schumacher <
> > felix.schumacher@internetallee.de> wrote:
> >
> >>
> >> Am 12. Oktober 2018 20:43:50 MESZ schrieb Philippe Mouawad <
> >> p.mouawad@ubik-ingenierie.com>:
> >>> Hello,
> >>>
> >>> Do we have a consensus on dropping RenderInBrowser ?
> >> I like it, as it gives a nicer rendering than the really old java
> >> component, but have to admit that JavaFX is going to be a lot harder to
> >> find in the default installation. And my pages are probably not the most
> >> complex ones, so there are no problems from missing resources.
> >>
> >> Has anyone has tried to get JavaFX as an Extremfall dependency into the
> >> build process?
> >>
> >> All in all I am +-0 to kick it out.
> >>
> >> Do we have a place for those old 'plugins'? That would be useful for the
> >> mongodb plugin, too.
> >>
> >> Regards,
> >>   Felix
> >>> Thanks
> >>> Regards
> >>>
> >>> On Fri, Oct 12, 2018 at 8:43 PM UBIK LOAD PACK Support <
> >>> support@ubikloadpack.com> wrote:
> >>>
> >>>> For information, as I think message was for mailing list.
> >>>>
> >>>> Regards
> >>>>
> >>>> ---------- Forwarded message ---------
> >>>> From: Milamber <mi...@apache.org>
> >>>> Date: Fri, Oct 5, 2018 at 8:19 AM
> >>>> Subject: Re: View Results Tree: Drop browser renderer
> >>>> To: UBIK LOAD PACK Support <su...@ubikloadpack.com>
> >>>>
> >>>>
> >>>> Hello,
> >>>>
> >>>> I'm agree to suppress this renderer. It's not very useful, bad
> >>> rendering
> >>>> and too slow.
> >>>>
> >>>> Milamber
> >>>>
> >>>> On 26/09/2018 08:55, UBIK LOAD PACK Support wrote:
> >>>>> Hello,
> >>>>> Isn't it time to drop Browser component and dependency on Java FX
> >>> in next
> >>>>> version ?:
> >>>>>
> >>>>>      - It is not available in OpenJDK which should become the most
> >>> used
> >>>> JVM ?
> >>>>>      It currently trigger an ugly stacktrace
> >>>>>      - It introduces complexity and did not offer that much interest
> >>> as
> >>>>>      initially expected
> >>>>>
> >>>>>
> >>>>> Regards
> >>>>>
> >>>>> On Thu, Apr 12, 2018 at 8:10 PM Felix Schumacher <
> >>>>> felix.schumacher@internetallee.de> wrote:
> >>>>>
> >>>>>> Am 07.04.2018 um 09:14 schrieb Philippe Mouawad:
> >>>>>>> Hello,
> >>>>>>> In jdk11, oracle will split javafx and javase.
> >>>>>>> This component uses javafx, I initially thought it would be a
> >>> better
> >>>>>>> renderer but due to security limitations on resources download,
> >>> it
> >>>> ended
> >>>>>> up
> >>>>>>> much less useful and rendering is always partial.
> >>>>>>>
> >>>>>>> So I propose to drop it in next 4.1 .
> >>>>>> Is there any chance to bypass the limitations on resource
> >>> download? I
> >>>>>> found the rendering to be a bit better than the built-in
> >>> "browser", but
> >>>>>> there is certainly a lot of room for improvement.
> >>>>>>
> >>>>>> Felix
> >>>>>>
> >>>>>>> Throughts?
> >>>>>>> Regards
> >>>>>>>
> >>>>>>>
> >>>>
> >>>>
> >>>> --
> >>>>
> >>>> Regards
> >>>> Ubik Load Pack <http://ubikloadpack.com> Team
> >>>> Follow us on Twitter <http://twitter.com/ubikloadpack>
> >>>>
> >>>>
> >>>> Cordialement
> >>>> L'équipe Ubik Load Pack <http://ubikloadpack.com>
> >>>> Suivez-nous sur Twitter <http://twitter.com/ubikloadpack>
> >>>>
> >
>
>

-- 
Cordialement.
Philippe Mouawad.

Re: View Results Tree: Drop browser renderer

Posted by Felix Schumacher <fe...@internetallee.de>.

Am 12.10.2018 um 21:44 schrieb Philippe Mouawad:
> Hello Felix,
>
> Thanks for your feedback.
> Regarding the place where to put them, frankly I don't know.
> Andrei proposed to make them available in jmeter-plugins plugins manager
> but required that we do the move to some github repo and contribute a
> plugin descriptor.
> I must say that for now, I feel it's too much work for me , which I prefer
> to invest on useful features.
>
> Should we create a github jmeter-legacy-plugins project ?
Would it be enough to create a new branch in our svn repository? That 
should be mirrored automatically to github.

What would be the plan for releasing those plugins?

If we donate them to someone outside of Apache, would we have to rename 
the packages and would old test plans still work?

Scratching my head.
  Felix

>
> Regards
>
>
>
>
> On Fri, Oct 12, 2018 at 9:39 PM Felix Schumacher <
> felix.schumacher@internetallee.de> wrote:
>
>>
>> Am 12. Oktober 2018 20:43:50 MESZ schrieb Philippe Mouawad <
>> p.mouawad@ubik-ingenierie.com>:
>>> Hello,
>>>
>>> Do we have a consensus on dropping RenderInBrowser ?
>> I like it, as it gives a nicer rendering than the really old java
>> component, but have to admit that JavaFX is going to be a lot harder to
>> find in the default installation. And my pages are probably not the most
>> complex ones, so there are no problems from missing resources.
>>
>> Has anyone has tried to get JavaFX as an Extremfall dependency into the
>> build process?
>>
>> All in all I am +-0 to kick it out.
>>
>> Do we have a place for those old 'plugins'? That would be useful for the
>> mongodb plugin, too.
>>
>> Regards,
>>   Felix
>>> Thanks
>>> Regards
>>>
>>> On Fri, Oct 12, 2018 at 8:43 PM UBIK LOAD PACK Support <
>>> support@ubikloadpack.com> wrote:
>>>
>>>> For information, as I think message was for mailing list.
>>>>
>>>> Regards
>>>>
>>>> ---------- Forwarded message ---------
>>>> From: Milamber <mi...@apache.org>
>>>> Date: Fri, Oct 5, 2018 at 8:19 AM
>>>> Subject: Re: View Results Tree: Drop browser renderer
>>>> To: UBIK LOAD PACK Support <su...@ubikloadpack.com>
>>>>
>>>>
>>>> Hello,
>>>>
>>>> I'm agree to suppress this renderer. It's not very useful, bad
>>> rendering
>>>> and too slow.
>>>>
>>>> Milamber
>>>>
>>>> On 26/09/2018 08:55, UBIK LOAD PACK Support wrote:
>>>>> Hello,
>>>>> Isn't it time to drop Browser component and dependency on Java FX
>>> in next
>>>>> version ?:
>>>>>
>>>>>      - It is not available in OpenJDK which should become the most
>>> used
>>>> JVM ?
>>>>>      It currently trigger an ugly stacktrace
>>>>>      - It introduces complexity and did not offer that much interest
>>> as
>>>>>      initially expected
>>>>>
>>>>>
>>>>> Regards
>>>>>
>>>>> On Thu, Apr 12, 2018 at 8:10 PM Felix Schumacher <
>>>>> felix.schumacher@internetallee.de> wrote:
>>>>>
>>>>>> Am 07.04.2018 um 09:14 schrieb Philippe Mouawad:
>>>>>>> Hello,
>>>>>>> In jdk11, oracle will split javafx and javase.
>>>>>>> This component uses javafx, I initially thought it would be a
>>> better
>>>>>>> renderer but due to security limitations on resources download,
>>> it
>>>> ended
>>>>>> up
>>>>>>> much less useful and rendering is always partial.
>>>>>>>
>>>>>>> So I propose to drop it in next 4.1 .
>>>>>> Is there any chance to bypass the limitations on resource
>>> download? I
>>>>>> found the rendering to be a bit better than the built-in
>>> "browser", but
>>>>>> there is certainly a lot of room for improvement.
>>>>>>
>>>>>> Felix
>>>>>>
>>>>>>> Throughts?
>>>>>>> Regards
>>>>>>>
>>>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Regards
>>>> Ubik Load Pack <http://ubikloadpack.com> Team
>>>> Follow us on Twitter <http://twitter.com/ubikloadpack>
>>>>
>>>>
>>>> Cordialement
>>>> L'équipe Ubik Load Pack <http://ubikloadpack.com>
>>>> Suivez-nous sur Twitter <http://twitter.com/ubikloadpack>
>>>>
>


Re: View Results Tree: Drop browser renderer

Posted by Philippe Mouawad <ph...@gmail.com>.
Hello Felix,

Thanks for your feedback.
Regarding the place where to put them, frankly I don't know.
Andrei proposed to make them available in jmeter-plugins plugins manager
but required that we do the move to some github repo and contribute a
plugin descriptor.
I must say that for now, I feel it's too much work for me , which I prefer
to invest on useful features.

Should we create a github jmeter-legacy-plugins project ?

Regards




On Fri, Oct 12, 2018 at 9:39 PM Felix Schumacher <
felix.schumacher@internetallee.de> wrote:

>
>
> Am 12. Oktober 2018 20:43:50 MESZ schrieb Philippe Mouawad <
> p.mouawad@ubik-ingenierie.com>:
> >Hello,
> >
> >Do we have a consensus on dropping RenderInBrowser ?
>
> I like it, as it gives a nicer rendering than the really old java
> component, but have to admit that JavaFX is going to be a lot harder to
> find in the default installation. And my pages are probably not the most
> complex ones, so there are no problems from missing resources.
>
> Has anyone has tried to get JavaFX as an Extremfall dependency into the
> build process?
>
> All in all I am +-0 to kick it out.
>
> Do we have a place for those old 'plugins'? That would be useful for the
> mongodb plugin, too.
>
> Regards,
>  Felix
> >
> >Thanks
> >Regards
> >
> >On Fri, Oct 12, 2018 at 8:43 PM UBIK LOAD PACK Support <
> >support@ubikloadpack.com> wrote:
> >
> >> For information, as I think message was for mailing list.
> >>
> >> Regards
> >>
> >> ---------- Forwarded message ---------
> >> From: Milamber <mi...@apache.org>
> >> Date: Fri, Oct 5, 2018 at 8:19 AM
> >> Subject: Re: View Results Tree: Drop browser renderer
> >> To: UBIK LOAD PACK Support <su...@ubikloadpack.com>
> >>
> >>
> >> Hello,
> >>
> >> I'm agree to suppress this renderer. It's not very useful, bad
> >rendering
> >> and too slow.
> >>
> >> Milamber
> >>
> >> On 26/09/2018 08:55, UBIK LOAD PACK Support wrote:
> >> > Hello,
> >> > Isn't it time to drop Browser component and dependency on Java FX
> >in next
> >> > version ?:
> >> >
> >> >     - It is not available in OpenJDK which should become the most
> >used
> >> JVM ?
> >> >     It currently trigger an ugly stacktrace
> >> >     - It introduces complexity and did not offer that much interest
> >as
> >> >     initially expected
> >> >
> >> >
> >> > Regards
> >> >
> >> > On Thu, Apr 12, 2018 at 8:10 PM Felix Schumacher <
> >> > felix.schumacher@internetallee.de> wrote:
> >> >
> >> >> Am 07.04.2018 um 09:14 schrieb Philippe Mouawad:
> >> >>> Hello,
> >> >>> In jdk11, oracle will split javafx and javase.
> >> >>> This component uses javafx, I initially thought it would be a
> >better
> >> >>> renderer but due to security limitations on resources download,
> >it
> >> ended
> >> >> up
> >> >>> much less useful and rendering is always partial.
> >> >>>
> >> >>> So I propose to drop it in next 4.1 .
> >> >> Is there any chance to bypass the limitations on resource
> >download? I
> >> >> found the rendering to be a bit better than the built-in
> >"browser", but
> >> >> there is certainly a lot of room for improvement.
> >> >>
> >> >> Felix
> >> >>
> >> >>> Throughts?
> >> >>> Regards
> >> >>>
> >> >>>
> >> >>
> >>
> >>
> >>
> >> --
> >>
> >> Regards
> >> Ubik Load Pack <http://ubikloadpack.com> Team
> >> Follow us on Twitter <http://twitter.com/ubikloadpack>
> >>
> >>
> >> Cordialement
> >> L'équipe Ubik Load Pack <http://ubikloadpack.com>
> >> Suivez-nous sur Twitter <http://twitter.com/ubikloadpack>
> >>
>


-- 
Cordialement.
Philippe Mouawad.

Re: View Results Tree: Drop browser renderer

Posted by Felix Schumacher <fe...@internetallee.de>.

Am 12. Oktober 2018 20:43:50 MESZ schrieb Philippe Mouawad <p....@ubik-ingenierie.com>:
>Hello,
>
>Do we have a consensus on dropping RenderInBrowser ?

I like it, as it gives a nicer rendering than the really old java component, but have to admit that JavaFX is going to be a lot harder to find in the default installation. And my pages are probably not the most complex ones, so there are no problems from missing resources. 

Has anyone has tried to get JavaFX as an Extremfall dependency into the build process?

All in all I am +-0 to kick it out. 

Do we have a place for those old 'plugins'? That would be useful for the mongodb plugin, too. 

Regards, 
 Felix 
>
>Thanks
>Regards
>
>On Fri, Oct 12, 2018 at 8:43 PM UBIK LOAD PACK Support <
>support@ubikloadpack.com> wrote:
>
>> For information, as I think message was for mailing list.
>>
>> Regards
>>
>> ---------- Forwarded message ---------
>> From: Milamber <mi...@apache.org>
>> Date: Fri, Oct 5, 2018 at 8:19 AM
>> Subject: Re: View Results Tree: Drop browser renderer
>> To: UBIK LOAD PACK Support <su...@ubikloadpack.com>
>>
>>
>> Hello,
>>
>> I'm agree to suppress this renderer. It's not very useful, bad
>rendering
>> and too slow.
>>
>> Milamber
>>
>> On 26/09/2018 08:55, UBIK LOAD PACK Support wrote:
>> > Hello,
>> > Isn't it time to drop Browser component and dependency on Java FX
>in next
>> > version ?:
>> >
>> >     - It is not available in OpenJDK which should become the most
>used
>> JVM ?
>> >     It currently trigger an ugly stacktrace
>> >     - It introduces complexity and did not offer that much interest
>as
>> >     initially expected
>> >
>> >
>> > Regards
>> >
>> > On Thu, Apr 12, 2018 at 8:10 PM Felix Schumacher <
>> > felix.schumacher@internetallee.de> wrote:
>> >
>> >> Am 07.04.2018 um 09:14 schrieb Philippe Mouawad:
>> >>> Hello,
>> >>> In jdk11, oracle will split javafx and javase.
>> >>> This component uses javafx, I initially thought it would be a
>better
>> >>> renderer but due to security limitations on resources download,
>it
>> ended
>> >> up
>> >>> much less useful and rendering is always partial.
>> >>>
>> >>> So I propose to drop it in next 4.1 .
>> >> Is there any chance to bypass the limitations on resource
>download? I
>> >> found the rendering to be a bit better than the built-in
>"browser", but
>> >> there is certainly a lot of room for improvement.
>> >>
>> >> Felix
>> >>
>> >>> Throughts?
>> >>> Regards
>> >>>
>> >>>
>> >>
>>
>>
>>
>> --
>>
>> Regards
>> Ubik Load Pack <http://ubikloadpack.com> Team
>> Follow us on Twitter <http://twitter.com/ubikloadpack>
>>
>>
>> Cordialement
>> L'équipe Ubik Load Pack <http://ubikloadpack.com>
>> Suivez-nous sur Twitter <http://twitter.com/ubikloadpack>
>>

Re: View Results Tree: Drop browser renderer

Posted by Philippe Mouawad <p....@ubik-ingenierie.com>.
Hello,

Do we have a consensus on dropping RenderInBrowser ?

Thanks
Regards

On Fri, Oct 12, 2018 at 8:43 PM UBIK LOAD PACK Support <
support@ubikloadpack.com> wrote:

> For information, as I think message was for mailing list.
>
> Regards
>
> ---------- Forwarded message ---------
> From: Milamber <mi...@apache.org>
> Date: Fri, Oct 5, 2018 at 8:19 AM
> Subject: Re: View Results Tree: Drop browser renderer
> To: UBIK LOAD PACK Support <su...@ubikloadpack.com>
>
>
> Hello,
>
> I'm agree to suppress this renderer. It's not very useful, bad rendering
> and too slow.
>
> Milamber
>
> On 26/09/2018 08:55, UBIK LOAD PACK Support wrote:
> > Hello,
> > Isn't it time to drop Browser component and dependency on Java FX in next
> > version ?:
> >
> >     - It is not available in OpenJDK which should become the most used
> JVM ?
> >     It currently trigger an ugly stacktrace
> >     - It introduces complexity and did not offer that much interest as
> >     initially expected
> >
> >
> > Regards
> >
> > On Thu, Apr 12, 2018 at 8:10 PM Felix Schumacher <
> > felix.schumacher@internetallee.de> wrote:
> >
> >> Am 07.04.2018 um 09:14 schrieb Philippe Mouawad:
> >>> Hello,
> >>> In jdk11, oracle will split javafx and javase.
> >>> This component uses javafx, I initially thought it would be a better
> >>> renderer but due to security limitations on resources download, it
> ended
> >> up
> >>> much less useful and rendering is always partial.
> >>>
> >>> So I propose to drop it in next 4.1 .
> >> Is there any chance to bypass the limitations on resource download? I
> >> found the rendering to be a bit better than the built-in "browser", but
> >> there is certainly a lot of room for improvement.
> >>
> >> Felix
> >>
> >>> Throughts?
> >>> Regards
> >>>
> >>>
> >>
>
>
>
> --
>
> Regards
> Ubik Load Pack <http://ubikloadpack.com> Team
> Follow us on Twitter <http://twitter.com/ubikloadpack>
>
>
> Cordialement
> L'équipe Ubik Load Pack <http://ubikloadpack.com>
> Suivez-nous sur Twitter <http://twitter.com/ubikloadpack>
>


-- 
Cordialement.
Philippe Mouawad.
Ubik-Ingénierie

UBIK LOAD PACK Web Site <http://www.ubikloadpack.com/>

UBIK LOAD PACK on TWITTER <https://twitter.com/ubikloadpack>

Fwd: View Results Tree: Drop browser renderer

Posted by UBIK LOAD PACK Support <su...@ubikloadpack.com>.
For information, as I think message was for mailing list.

Regards

---------- Forwarded message ---------
From: Milamber <mi...@apache.org>
Date: Fri, Oct 5, 2018 at 8:19 AM
Subject: Re: View Results Tree: Drop browser renderer
To: UBIK LOAD PACK Support <su...@ubikloadpack.com>


Hello,

I'm agree to suppress this renderer. It's not very useful, bad rendering
and too slow.

Milamber

On 26/09/2018 08:55, UBIK LOAD PACK Support wrote:
> Hello,
> Isn't it time to drop Browser component and dependency on Java FX in next
> version ?:
>
>     - It is not available in OpenJDK which should become the most used
JVM ?
>     It currently trigger an ugly stacktrace
>     - It introduces complexity and did not offer that much interest as
>     initially expected
>
>
> Regards
>
> On Thu, Apr 12, 2018 at 8:10 PM Felix Schumacher <
> felix.schumacher@internetallee.de> wrote:
>
>> Am 07.04.2018 um 09:14 schrieb Philippe Mouawad:
>>> Hello,
>>> In jdk11, oracle will split javafx and javase.
>>> This component uses javafx, I initially thought it would be a better
>>> renderer but due to security limitations on resources download, it ended
>> up
>>> much less useful and rendering is always partial.
>>>
>>> So I propose to drop it in next 4.1 .
>> Is there any chance to bypass the limitations on resource download? I
>> found the rendering to be a bit better than the built-in "browser", but
>> there is certainly a lot of room for improvement.
>>
>> Felix
>>
>>> Throughts?
>>> Regards
>>>
>>>
>>



-- 

Regards
Ubik Load Pack <http://ubikloadpack.com> Team
Follow us on Twitter <http://twitter.com/ubikloadpack>


Cordialement
L'équipe Ubik Load Pack <http://ubikloadpack.com>
Suivez-nous sur Twitter <http://twitter.com/ubikloadpack>

Re: View Results Tree: Drop browser renderer

Posted by UBIK LOAD PACK Support <su...@ubikloadpack.com>.
Hello,
Isn't it time to drop Browser component and dependency on Java FX in next
version ?:

   - It is not available in OpenJDK which should become the most used JVM ?
   It currently trigger an ugly stacktrace
   - It introduces complexity and did not offer that much interest as
   initially expected


Regards

On Thu, Apr 12, 2018 at 8:10 PM Felix Schumacher <
felix.schumacher@internetallee.de> wrote:

> Am 07.04.2018 um 09:14 schrieb Philippe Mouawad:
> > Hello,
> > In jdk11, oracle will split javafx and javase.
> > This component uses javafx, I initially thought it would be a better
> > renderer but due to security limitations on resources download, it ended
> up
> > much less useful and rendering is always partial.
> >
> > So I propose to drop it in next 4.1 .
> Is there any chance to bypass the limitations on resource download? I
> found the rendering to be a bit better than the built-in "browser", but
> there is certainly a lot of room for improvement.
>
> Felix
>
> > Throughts?
> > Regards
> >
> >
>
>

-- 

Regards
Ubik Load Pack <http://ubikloadpack.com> Team
Follow us on Twitter <http://twitter.com/ubikloadpack>


Cordialement
L'équipe Ubik Load Pack <http://ubikloadpack.com>
Suivez-nous sur Twitter <http://twitter.com/ubikloadpack>

Re: View Results Tree: Drop browser renderer

Posted by Felix Schumacher <fe...@internetallee.de>.
Am 07.04.2018 um 09:14 schrieb Philippe Mouawad:
> Hello,
> In jdk11, oracle will split javafx and javase.
> This component uses javafx, I initially thought it would be a better
> renderer but due to security limitations on resources download, it ended up
> much less useful and rendering is always partial.
>
> So I propose to drop it in next 4.1 .
Is there any chance to bypass the limitations on resource download? I 
found the rendering to be a bit better than the built-in "browser", but 
there is certainly a lot of room for improvement.

Felix

> Throughts?
> Regards
>
>