We could check for the presence of HTMLParser at run-time, and fall back to
JTidy or Regex (or etc.) if not present.
Some users might not like the fallback behaviour, so if the parser property
were changed to be a list of the acceptable parsers, in order of preference,
we could support as much
I guess I'm the only one with the bias towards better performance at the cost of
increased maintenance. If everyone prefers to default to JTidy and require users
download HTMLParser, I have no objections.
I just would rather make it easier on the user and not add another jar file for users
we have a license to keep the source in CVS but not a binary jar?
On 5 Feb 2004 at 5:52, peter lin wrote:
I guess I'm the only one with the bias towards better performance
at the cost of increased maintenance. If everyone prefers to default
to JTidy and require users download HTMLParser, I
Jordi Salvat i Alabart [EMAIL PROTECTED] wrote:
+0 on keeping htmlparser code in our codebase -- at least for the time
being.
+0 on switching default parser to htmlparser. Performance-wise, I would
vote for the regex one, but I don't really trust its accuracy (although
it is working very
-Original Message-
From: peter lin [mailto:[EMAIL PROTECTED]
Sent: 05 February 2004 18:48
To: JMeter Developers List
Subject: Re: How to handle htmlparser library (was Are we ready for a
RC?)
tion component.
I just doubled checked and it looks, HTMLParser is the default.
private final
