Return-Path: Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm Delivered-To: mailing list ant-dev@jakarta.apache.org Received: (qmail 93379 invoked from network); 29 Aug 2000 19:48:13 -0000 Received: from unknown (HELO shofar.appliedreasoning.com) (209.242.122.87) by locus.apache.org with SMTP; 29 Aug 2000 19:48:13 -0000 Received: from job ([10.0.1.2]) by shofar.appliedreasoning.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id PAA24705 for ; Tue, 29 Aug 2000 15:00:12 -0500 Date: Tue, 29 Aug 2000 15:44:00 -0400 From: Chris Grindstaff X-Mailer: The Bat! (v1.45) Personal Reply-To: Chris Grindstaff Organization: Applied Reasoning X-Priority: 3 (Normal) Message-ID: <177365969936.20000829154400@appliedReasoning.com> To: ant-dev@jakarta.apache.org Subject: Re: [PATCH] Speed increase to Javadoc task In-reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N Speaking of Javadoc does anyone know of a decent alternative? Javadoc is fine to use (albeit slow) - but try extending it. I simply can't get enough of private final members ;-) It only adds insult to injury reading the comments. Other Sun developers ran into the same sort of problems I'm having, but they're in the "blessed" package. Grrr. Oh yeah - I'm being protected from future changes and myself. :-) All joking aside the biggest problem that I've had with Sun's stuff is with their model objects. PackageDoc, ClassDoc, etc. Sun wrote their stuff assuming that you would not want to modify those classes without completely rewriting them or copying them. About the only thing I've run into is: http://home.austin.rr.com/kjohnston//javasrc.htm Chris Tuesday, August 29, 2000, 3:11:10 PM, glennm glennm wrote: gcic> Hey all. gcic> As I said in a previous note, the current Javadoc task was unnecessarily gcic> (although very thoroughly) checking each .java fie in the source path for gcic> its package. The unfortunate part about it is that Javadoc itself can't gcic> deal with .java files in the wrong directory. So, there really isn't any gcic> need to check each and every file for its package, unless the Javadoc tool gcic> in JDK1.3 can handle this situation. I didn't check that one, to be gcic> honest, but I'm not too hopefull. gcic> At any rate, I've created a patch that removes the scanning of individual gcic> files and simply scans the directory structure for potential packages. The gcic> name matching rules still apply. gcic> To provide a comparison, I have a source tree with 3, 605 java files. I gcic> only need to document 63 of those files in five packages during one gcic> particular run of Javadoc. With the old Javadoc task, it took 00:01:17. gcic> With the new Javadoc task, it took 00:00:21. You decide. :-) gcic> Glenn McAllister gcic> Software Developer. IBM Toronto Lab, (416) 448-3805 gcic> "An approximate answer to the right question is better than the gcic> right answer to the wrong question." - John W. Tukey -- Chris Grindstaff chrisg@appliedReasoning.com | www.appliedReasoning.com