Maybe I misunderstood but xjavadoc testing will be different from what I am doing no ? You want to unit test xjavadoc as a standalone product. What I am doing is "only" regression testing of xdoclet generated class/xml files. If this is right, what you can get from my work is "only" the build scripts, the html report generation,... pure junit stuffs. ... And the Class/Method/Field comparators : is this that you want ? Tell me cause I will need to rearrange these (package naming) for possible use inside xjavadoc.
Anyway, I will commit my work tonight "as it is" so you can have a look. I hope for my part to get some time to see your "beautiful baby". 5 times faster than javadoc! absolutely fabulous :))) BTW, maybe you could try to ping Rickard's attention, if one have to do better on performance he is surely a Big one. ;) Regards. Vincent. --- Ara Abrahamian <[EMAIL PROTECTED]> wrote: > 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 > === message truncated === __________________________________________________ Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games http://sports.yahoo.com _______________________________________________ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
