Hello, Can I drop Browser Renderer for 5.1 version ? Regards
On Fri, Oct 12, 2018 at 10:39 PM Philippe Mouawad < [email protected]> wrote: > > > On Fri, Oct 12, 2018 at 10:35 PM Felix Schumacher < > [email protected]> 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 < >> > [email protected]> 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 < >> >>> [email protected]> wrote: >> >>> >> >>>> Am 12. Oktober 2018 20:43:50 MESZ schrieb Philippe Mouawad < >> >>>> [email protected]>: >> >>>>> 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 < >> >>>>> [email protected]> wrote: >> >>>>> >> >>>>>> For information, as I think message was for mailing list. >> >>>>>> >> >>>>>> Regards >> >>>>>> >> >>>>>> ---------- Forwarded message --------- >> >>>>>> From: Milamber <[email protected]> >> >>>>>> Date: Fri, Oct 5, 2018 at 8:19 AM >> >>>>>> Subject: Re: View Results Tree: Drop browser renderer >> >>>>>> To: UBIK LOAD PACK Support <[email protected]> >> >>>>>> >> >>>>>> >> >>>>>> 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 < >> >>>>>>> [email protected]> 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.
