I have committed a lotta new stuff. you bold ones go ahead and try it. the code is a bit messy, but i thought i'd need some comments from you before i start tidying up.
here is a brief description about how it works: the xjavadoc package contains the "public" part of xjavadoc. these classes resemble the javadoc api. the main difference is that xjavadoc has separated the code level and the comment level. there are a lot of classes that represent code constructs, but only one class that represent docs (XDoc). javadoc had mixed code and comments in the same classes (most javadoc classes are subclasses of Doc). there are source and binary implementations for the XClass interface. This is required to get the full class hierarchy when some classes are only available as compiled classes. the core package (will be renamed to ant I think) only contains the ant task. this is a thin wrapper around the XJavaDoc class, and the ant task is not strictly needed. it only does the directory scanning. the javacc folder contains a JJTree grammar for the Java language. JavaCC/JJTree is a code generator that generates java source code. This source code goes in the ast package. -So what are these classes? The AST*** classes each represent a java program element, such as an import statement, a package declaration, a class declaration, a for loop, etc. Tha JavaParser class can parse an input stream containing a java source file, and generates a tree structure of different AST objects. The topmost node in the tree is an ASTCompilationUnit, and this represents the whole class. The immediate nodes under this object is typically one or more import declarations etc. (see the grammar file). The parser can return such a tree for any java source file, and then we can start examining what's in the source file by accessing objects. This is done with visitors (JJTree adds visitor support to JavaCC). The JavaDocVisitor traverses a tree that the parser has created, extracts information every time it visits various nodes, and builds a new datastructure (the xjavadoc.* classes). This is done for all the classes that are passed to the ant task, and the result is a data structure similar to the data structure that JavaDoc provides. I have planned for code mutation. The syntax tree is kept, so new nodes (like method nodes) can be inserted at desired locations. a special print visitor can traverse the tree and print it out to a (file) output stream. The most important thing right now is not code mutation, but make xjavadoc complete enough so it can replace javadoc in xdoclet. That would be a good start. I tried running xjavadoc on the JDK sources, but it fails on some of the classes, notably classes that define inner classes with a ; after the last }. According to the language spec, this semicolon is not allowed, but javac seems to accept them. Jikes doesn't AFAIK. I think xjavadoc needs to be relaxed and accept this kind of rubbish. Also, we should stop parsing when we get to a method declaration. We don't care about the body of a method, do we? It would improve performance. Enough blabla. You get the picture I hope. Play around with it a bit and feed back. Aslak _______________________________________________ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
