I hope you'll commit it asap so we can base the xjavadoc testing system on it.
Ara. > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:xdoclet-devel- > [EMAIL PROTECTED]] On Behalf Of Vincent Harcq > Sent: Monday, February 25, 2002 11:16 AM > To: 'David Jencks'; [EMAIL PROTECTED] > Subject: RE: [Xdoclet-devel] xjavadoc TODOs > > 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 _______________________________________________ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
