Thanks David, I have almost finished InterfaceComparator, ClassComparator, which use MethodComparator and FieldComparator. I miss a XMLComparator, I will try to implement yours.
FYI: I created a new package under core (so at the same level than samples) with brand new classes that are xdoclet tagged. [We could also run the tests for samples but changing the samples to handle all test cases is a bad idea imho.] I generate from them and save generated files as reference under another package (the class Name must be the same) Then I compare (using my new stuffs) interfaces and implemented classes at the reflection level (does all methods throws same exceptions, ...) When a new bug is found, we have to change the xdoclet tagged bean, generate from it, change the reference generated file BY HAND (!), do the unit test case again until it does not break. It works fine, this may seem a bit unnecessary but I already spotted one bug :( The base xdoclet tagged beans have all possibilities that ejb spec handles (ejbCreatexxx() for example) I will begin CMP and will do something like AllEntityTypesBean to be sure (recent bug post on byte[]...) I leaved an entry in ClassComparator to "xjavadoc compare" (or something else) the internal of a method later... When I will come to tests each tag and each attributes in a tag, and also Component Inheritance, it may become a painful job but imho we have to do that... The XMLComparator will also be the most important part because it is in xml generation that problems arrises most of the time. Regards. Vincent > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]] On Behalf > Of David Jencks > Sent: lundi 25 f�vrier 2002 8:03 > To: [EMAIL PROTECTED] > Subject: Re: [Xdoclet-devel] xjavadoc TODOs > > > Well I've been mentioning it for a while but haven't had time > to set it up, but I've attached my xml comparator. You give > it 2 nodes and it gives you back an element listing the > differences with navigation info. I didn't know xpath when I > wrote it, which might be a better way of showing where the > differences are. > > If it saves someone a few hours writing something, great, if > it's not appropriate, that's fine too. > > Thanks > david jencks > > On 2002.02.25 01:28:04 -0500 Ara Abrahamian wrote: > > > I am very inexperienced with threads, so I would never > have spotted > > the > > > deadlock by just reading the code. > > > Did you "see" it or did you experience the deadlock, > Konstantin? If > > you > > > saw > > > it, Im really impressed, because > > > I have tried to understand threads for a very long time, > and I never > > seem > > > to > > > get it completely. > > > > I experienced it in classdump. Classdump is a good and > realistic test! > > Btw, it hangs when a syntax error is reported by javacc!! I > think we > > need to take a look at javacc's error handling docs :-) > > > > > Anyway, we're now three active committers on xjavadoc, and that's > > > good > > for > > > time-to-market. I'm still baffled with > > > the multithreading approach Ara came up with. I only > implementeded > > > it. > > By > > > now it seems to me you're both very much > > > up to speed with xjavadoc's under the hood workings. Isn't JavaCC > > great? > > > > Absolutely! > > > > > One way to solve it is to provide two different parsers, one with > > unicode > > > enabled and one without. Can be achieved > > > by preprocessing the grammar with XDoclet's ReplaceCopy task (see > > samples) > > > and generate parser into two different > > > packages. Then we can add a -unicode runtime flag which indicates > > which > > > one > > > to use. > > > > Agree but you're talking about how much performance decrease?! > > > > > 2) Class resolving. I have experienced some problems if a class > > imports > > > both > > > a package (say foo.bar.*) and also > > > a class in the same package (say foo.bar.Grunt), because of > > > ambiguity. > > I > > > have solved this temporarily by juggling > > > in SourceClass.qualify(). -But we should verify with the java > > > language spec to see what the exact semantics are. > > > > Yup, I guess it'll fail because we find two classes in two > tests and > > we don't check if it's the already found one! Very easy to fix. > > > > > 3) Trailing ; (semicolons). Many sources have kinda this: public > > > abstract Foo bar();; or > > > public Foo bar() {}; > > > or something like that.. > > > > > > The issue is that this is wrong according to the language > spec, but > > both > > > javac and javadoc accepts it, and therefore > > > there will always be some sources around that uses it. If > there is > > > an > > easy > > > way (which doesn't degrade persformance) > > > to make the grammar accept it, we'll support it. > Otherwise not. It's > > not > > > hard for people to remove some semicolons > > > as long as xjavadoc reports where the problem is (it > does). -But you > > > should be aware of it, because it will happen if you > > > run xjavadoc on large sources like Ant or Xalan. > > > > Isn't it a matter of a (SEMICOLON)* after each block? > > > > > 4) We should design a little class hierarchy with as many > oddities > > > as possible and use that as test data for our JUnit > tests. The Hello > > > alone is no good, neither are the xdoclet > > samples. > > > They're too ordinary. What we need to test > > > especially is: > > > -javadocs in front of methods/classes with/without modifiers > > > (Because > > as > > > far > > > as the parser is concerned, the modifier/no modifier > situations are > > > treated differently). -tricky import ambiguities (as described > > > above). -nested inner classes. > > > -anonymous inner classes. > > > -references to nonexisting classes (like there is a lot > of when you > > use > > > xdoclet). > > > -modifying docs (on methods/classes with/without modifiers) and > > > saving them. > > > > Concentrate on xdoclet's usage scenarios for the time being :-) > > > > > -reading back the modified and saved classes and do > asserts in junit > > test. > > > -adding docs to undocumented classes/methods, both with > and without > > > modifiers -verify that we don't have any more deadlocks/race > > > conditions. -verify that the tag parameter stuff works > properly for > > > read,update > > and > > > delete (update should do an add if the tag doesn't exist) -verify > > > that doc indentation is aligned with the class or method > when saving > > > (must do this manually) > > > -do all the above that applies to fields and methods too. > > > -test if sources with unicode escapes work properly. > > > -this list (plus your additions) should be in the header of the > > > XJavaDocTest > > > class(es), so we can mark whether the tests are > implemented or not) > > > -the test hierarchy should of course compile, and the junit target > > shoul > > > depend on them being compiled. > > > > This is a great summary of various ambiguous cases, you've thought > > about it deeply! > > > > Since plugging it in xdoclet is a major project itself we should > > handle "Doclet API compatibility test" with testing for > equal results > > with Sun's API. What you guys think about a XML outputer for both > > Sun's API and ours and check for their equality? I believe it'll be > > useful for other cases too, we can use the xml equality code for > > testing ejb-jar.xml and other xmls for example. > > > > > One other idea I have is to write a javadoc doclet which > scans a big > > > source tree and generates JUnit test classes (using xdoclet's > > > template engine.) This is a good way to test if xjavadoc works the > > same > > > way > > > as javadoc. This shouldn't be too hard to do, and it > > > would make us really sure that xjavadoc is ready for action. > > > > "generates JUnit test classes"? I don't get it. > > > > > I'll be very busy this week, and won't be able to do much, and the > > week > > > after I'm on holiday (skiing in switzerland, yohoo), > > > > Have fun ;-) > > > > > so I hope you can start on some of this. I'll leave it up > to you to > > > prioritise the items and assign them among us. This > should really be > > > added to the SF tracker under xjavadoc, but I don't > > have > > > time to do that now. > > > > Yup. Konstantin, what's your schedule? What you're interested in? > > > > Ara. > > > > > > > > _______________________________________________ > > Xdoclet-devel mailing list [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/xdoclet-devel > > > > > _______________________________________________ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
