On Fri, Oct 12, 2018 at 10:35 PM Felix Schumacher < felix.schumac...@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.schumac...@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.schumac...@internetallee.de> wrote: > >>> > >>>> Am 12. Oktober 2018 20:43:50 MESZ schrieb Philippe Mouawad < > >>>> p.moua...@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 < > >>>>> supp...@ubikloadpack.com> wrote: > >>>>> > >>>>>> For information, as I think message was for mailing list. > >>>>>> > >>>>>> Regards > >>>>>> > >>>>>> ---------- Forwarded message --------- > >>>>>> From: Milamber <milam...@apache.org> > >>>>>> Date: Fri, Oct 5, 2018 at 8:19 AM > >>>>>> Subject: Re: View Results Tree: Drop browser renderer > >>>>>> To: UBIK LOAD PACK Support <supp...@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.schumac...@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.
