Return-Path: Delivered-To: apmail-jakarta-ant-user-archive@apache.org Received: (qmail 96425 invoked from network); 21 Aug 2002 18:06:47 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 21 Aug 2002 18:06:47 -0000 Received: (qmail 2551 invoked by uid 97); 21 Aug 2002 18:07:08 -0000 Delivered-To: qmlist-jakarta-archive-ant-user@jakarta.apache.org Received: (qmail 2534 invoked by uid 97); 21 Aug 2002 18:07:08 -0000 Mailing-List: contact ant-user-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Ant Users List" Reply-To: "Ant Users List" Delivered-To: mailing list ant-user@jakarta.apache.org Received: (qmail 2509 invoked by uid 98); 21 Aug 2002 18:07:07 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Message-ID: <20020821180633.10752.qmail@web20417.mail.yahoo.com> Date: Wed, 21 Aug 2002 11:06:33 -0700 (PDT) From: Matt Benson Subject: Re: Build Javadocs on subset of src directory To: Ant Users List In-Reply-To: <033901c2493c$a9591c10$1464a8c0@sv.embracenetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N I realize there were other problems; I just thought I'd take a quick stab at that simple problem. I understand the "unwillingness to change" issue, but ordinarily the way to have classes (inner or otherwise) that are used as part of the innerworkings of a package but about which we do not want our clients to know is to give these classes default or package-private access or whatever you want to call it. Just because you don't include it in the Javadoc doesn't mean somebody won't try to use it. :) -Matt --- Ritesh Trivedi wrote: > > > > The most common way, I would think, to suppress > the > > generation of Javadocs for inner classes is with > > access specifiers on the classes themselves and at > > generation time with Javadoc. > > Valid point, but its just part of the problem, the > other part is its > generating javadocs for the classes which I dont ask > it to! > But there are a few points against changing the > access specifiers > > - Usually ppl dont want to change the java source > files just becoz javadocs > needs to be generated! atleast thats the mentality I > have found in ppl. This > is a problem especially if I am not the author of > the class > - Another even greater reason is the inner class > might be public to be used > by internal system classes but not necessarily > explosed to the > Customers/Developers through the javadoc > > I can deal with inner class issue, but what I am > more concerned about it > those extra classes that get documented even if I > havent asked for it in the > first place. > > > If the inner class is > > not part of the public API (which you want to > > Javadoc), then why make it public? > > > > -Matt > > > > --- Ritesh Trivedi > wrote: > > > Hi, > > > > > > I have tried looking at the mailing list since > past > > > 24 hrs to find answer to this, but no success. > Sorry > > > for the bandwidth ahead of time. > > > > > > I have a situation where I need to generate > javadocs > > > for the subset of the source directory which > > > contains java source files which should be > exposed > > > via Javadocs. > > > > > > What I do currently is, I copy only those files > > > which I want javadocs generated for to a temp > > > directory and call javadocs task from my > build.xml > > > on that temp source directory. But the problem > with > > > this approach is, its generating javadocs for > files > > > that I didnt ask it to!! I think its picking > those > > > extra classes up from the classpath!! On top of > that > > > its generating javadocs for the innner classes > too! > > > which I dont want. > > > > > > Another thing I tried was to put a fileset > inside > > > the javadoc task and exclude the files which I > dont > > > want, still its generating more files than I ask > it > > > to! > > > > > > Does anyone know a better way of doing this? > > > > > > Thanks > > > > > > Ritesh > > > > > > ================================ > > > Ritesh Trivedi > > > Embrace Networks > > > 408-585-5621 > > > > > > __________________________________________________ > > Do You Yahoo!? > > HotJobs - Search Thousands of New Jobs > > http://www.hotjobs.com > > > > -- > > To unsubscribe, e-mail: > > > For additional commands, e-mail: > > > > > > -- > To unsubscribe, e-mail: > > For additional commands, e-mail: > > __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com -- To unsubscribe, e-mail: For additional commands, e-mail: