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.
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>
