> - should the modules' builds really be doing their docs as well, or should > they leave it till the build-docs script to do it? i.e. have the > ModulesGrandBuilder just run the jar target, and do the docs later. It > seems to me that the OutOfMemoryExceptions happen mainly in the anakia > tasks, so it may be able to compile & build the jars in one go if it > wasn't > doing that as well. > > - the clean target in the main build file doesn't remove the generated > project.xml. On occasion, I've had the docs build drop out with an > OutOfMemoryException and leave project.xml half completed. Trying to > build > even the core then failed with an error in the anakia target (while > building > the xdoclet module); again, does it need to do the docs at this stage > anyway?
I'm working on this OOM exception. Very tricky code, because of all those back pointers from XDoc to SourceClass/MethodImpl and so on. Way too many referrers to an object. > - is there any way to avoid compiling the whole xdoclet module just to get > the externalizer to run over the core classes? I had a brief attempt at > trying to move the externalizer stuff across into the java module when I > was > adding Laurent's beaninfo subtask, but couldn't separate them. Couldn't > it > compile just the externalizer classes into a separate directory, and use > those for the rest of the build (including building the module the > externalizer goes into)? Or will this not work because of needing an > xdoclet.xml? Yes, it's a module and a module to be found by xdoclet needs to have the dd file. Btw, are we going to include xdocletgui in this release? I assume yes. So is the bundling/dist ready for it? How is it going to be packaged inside xdoclet.zip distro? Ara. ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
