> > > > Why cache to XML if you're looking for super performance? Wouldn't > > > > serialized objects be even quicker? I haven't a clue how xjavadoc works > > > > internally, but my hunch is that it builds an object graph representing > > > > classes/methods/fields and their @tag data. > > > > > > > > Just an idea.... dunno if loading serialized objects is faster than SAX on > > > > XML files and rebuilding the object graphi, but seems like it would be. > > > > > > > > Erik
> Now Thinking Out Loud: > The other driver, not much less important, would be usability! Like I said, > using an XML format certainly opens doors to many other tools which process > XML like XSLT and Schema validation. Hence, XML should be the number one > exchange format between XJavaDoc and XDoclet! Every XDoclet would simply be > a SAX ContentHandler and can do the same things they're doing now > (generating descriptors, html, sourcefiles) or/and other SAX ContentHandlers > (XSLT, validation). > > Is this just plain stupid or might this actually work!? I would like to take the opportunity to explain the usablity part I mentioned above. Surcecode contains valuable information, not just for the Java compiler. That's why we have JavaDoc, which reads human-readable information (HTML text) and attributes (tags) and processes it to a convenient HTML documentation system. Today we use more tools which do 'something' with sourcecode: JUnit, CVS, metrics and bug tracking to take a few. Each of these tools produce reports or logs which say something about the sourcecode: failing tests, CVS revisions, complexity numbers, number of open bugs (...) etc. Together they contain invaluable information about the same unit of sourcecode. Having this information one might see patterns like having a large complexity number yields lots of CVS revisions and bug reports. Or a solved bug resulted in which testcases to succeed (again) with which patch against CVS. Or the # of bugs per LOC in a graph put out against time, with lines denoting release dates, whatever. If this information is easily gathered and stored in a database, you are able to keep track of changes and so build historical data ... voila, a Developers Data Warehouse! I would definately like to have some tools which support this database stuff... Ciao, BG _______________________________________________ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
