howdy

i've just committed a big bunch of updates to xjavadoc. since last time i
have added an utility that writes the javadoc for a source tree to one xml
file. (it's something i've "borrowed", and shouldn't be part of xjavadoc
itself). i have written a classic javadoc adapter too, plus a doclet-like
plugin api. when i run classic javadoc and xjavadoc on xjavadoc's own source
i get nearly identical xml files, which is a good indication that i'm close
to good enough.

currently xjavadoc is a little bit slower than javadoc, but i haven't tried
to optimize anything. source code is a bit messy, and needs refactoring.
further, some additional interfaces should be added to make the migration
easier (all classes that have a doc() method should implement a Documented
interface).

next time i come out of my cave i'll provide a better build script (which
can build javadoc for xjavadoc) and some more general docs. there is no code
mutation support yet, i'll let it rest until the core engine is more mature.

here is how i think we should migrate whenever we want to start:
1) make a new refactor branch for xdoclet (WHO CAN DO? I DON'T KNOW HOW TO
DO THIS IN CVS).
2) clean up xdoclet's import statements with
http://sourceforge.net/projects/importscrubber. it'll make the
search/replace easier.
3) write a perl/python script or something that can walk over xdoclet's
source code and replace the old javadoc classes with xjavadoc classes. (I
DON'T KNOW ANY OF THESE LANGUAGES, SO I NEED HELP). this will make the
migration effort easier once we want to migrate the main branch (which i
assume will evolve with lightning speed in the meanwhile as usual).

what do you think? anybody want to dig in soon? i'm getting lonely here ;-)

aslak


_______________________________________________
Xdoclet-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xdoclet-devel

Reply via email to