> > yeah - the main problem being that at some stage someone would need to > > sit down and do a sizable chunk of up-front work. how about, > > use jenesis to parse the cvs version of an generated file, then parse the > > new generated file, and do a content comparison - that > > would avoid the whitespace problem, and avoid someone having to do the > > upfront programming, and the maintainence. on the bad side, > > I imagine it'd be dog slow as a test. so have that for source code, your > > xml comparator for xml output, and we should have a pretty > > solid "change observer" > > > > thoughts? > > > I was thinking more in terms of putting the binary class files from > compiling the "known good" generated source in cvs, and doing "comparative > introspection" on them. I haven't tried it, but I imagine it would be > pretty easy - get all the reflective stuff from each class and compare. > > I guess it would be better to put "known good" java source in cvs, and > compile both "known good" and "newly generated" each time to compare.
but that will only give you down to method level. something like me breaking the hashCode last week wouldn't be picked up - mind you, that was a compilation error... but you know what I mean. down to the statement level would be very thorough... I suppose the only thing is is it too thorough? cheers dim _______________________________________________ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
