* Erik Abele wrote:
To quote you from another mail on the dev@ list: 'A feature that can't be disabled is a *bug*' (Message-ID: <[EMAIL PROTECTED]>). Therefore, I consider this definitely as a bug ;-)
ehm, yes ;-) *mumblesomething*
hehe ;-)
However. I'm not happy with that solution, since it adds a dependency to the process that is (currently) not needed. If we consider sometime not to distribute the entity files (that are only required for the transformation process), we may simply re-add the stuff, that's now in. The .dtds are already referenced absolute and with publicId, so there's no problem.
Well, I'm going fine with this; we don't _need_ it now, that's right, but I just can't see how 8 (?) lines complicate the build process so much and IMO 'foreign' resources should be referenced to their original source instead of referencing them with local copies, but that's more a personal thing...
Hmm. seems really to be a question of taste. So I'm putting a +/- 0 ;-)
To be really honest: this might not the best possible solution for everybody, but I don't see it doing any harm, so +/- 0 from me too ;-)
However, another more important concern is Ants memory usage. After playing with some entities I realized strong problems: just randomly touch some files in the manual dir and add some entities (e.g. ©) to some of them. Then build. I'm always getting OutOfMemory failures and can only build the whole tree after calling build.sh several times. I don't know if it's machine-dependent (I can currently build only on redhat8.0, P4/128MB, will test it later with 1GB RAM on freebsd) but I would like to hear some other experiences with this. Perhaps the conclusion is, that we have to back out the whole entity-thing :-(
Cannot reproduce it with first tests. But this may be dependant on my "optimized" java call. I increased the thread stack size already some time ago (while playing around with design improvements...)
fine, sounds good. I also couldn't recreate the mentioned problems on my home machine...
i.e. the commandline options
-Xmx128m -mx128m
set the stack size to 128K instead of 64 (default in newer java machines, at least on win32). found this on the xalan pages (I believe).
Ahh, interesting; didn't know that, but will try tomorrow. Perhaps this will eleminate some other problems I had with this machine ;-)
cheers, erik
