On Fri, Apr 16, 2004 at 11:47, Pierre van Rooden wrote:
> There may be some improvements that can be made - a lot of the original
> code is static and I am unsure if that can cause problems if multiple
> threads use the code (probably not, just not sure).
> I have downloaded a version of xmlbs from may 2003 (not sure if that is
> the last one). It uses several jars that I would rather leave out (maybe
> I do not need all of them in a production environment?).
There is one race-condition in the code that I know of; the RE objects
are precompiled and stored statically instead of REPrograms, RE
objects are not likely to be threadsafe. The static code is not a
problem since all the static fields accessed are final or should be.
XMLbs depends on 3 jars;
- jakarta-regexp
This dependency will be drop in the near future. I want to port
xmlbs to 1.4 to use the native regexp engine (and fix the race
condition). Of course this means it will not work on 1.3 anymore.
- junit
Otherwise the unit tests won't compile and run. For the
wordhtmlcleaner this is not a runtime dependency.
- java-getopt
Getopt is only used in the XHTMLize class, a commandline tool I use
to cleanup my hand crafted HTML files. This also doesn't have
significanse to the wordhtmlcleaner.
After porting to 1.4, neither of the above jars files should be a
problem when I provide a precompiled jar-file on the xmlbs site. I am
not sure where mmbase stand now on the 1.4 issue, can anybody enlighten
me?
> Anyway I was thinking if and how this can be bundled in an application
> for download (assuming Nico and Remko think this is a plan). And where
> it would be best to store sources.
> The speeltuin is an idea, though ofcourse one can also decide to reverse
> the logic and put the MMBase-plugin on the xmlbs site?
> I can hardly decide this myself, as I only added a few lines to already
> existing code, but I think this plugin would be very useful to a lot of
> people, and using the new field hooks it becomes a lot more versatile.
I don't like to add mmbase centric code to this codebase since it will
add undesired build dependencies. A precompiled jar-file should be easy
to work with from an mmbase point of view and the wordhtmlfilter should
probably be moved from the speeltuin to the modules or util or whatever
package.
Remco
