Return-Path: 
 <forrest-dev-return-4147-apmail-xml-forrest-dev-archive=xml.apache.org@xml.apache.org>
Delivered-To: apmail-xml-forrest-dev-archive@xml.apache.org
Received: (qmail 24007 invoked by uid 500); 13 Dec 2002 13:50:16 -0000
Mailing-List: contact forrest-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:forrest-dev-help@xml.apache.org>
list-unsubscribe: <mailto:forrest-dev-unsubscribe@xml.apache.org>
list-post: <mailto:forrest-dev@xml.apache.org>
Reply-To: forrest-dev@xml.apache.org
Delivered-To: mailing list forrest-dev@xml.apache.org
Received: (qmail 23989 invoked from network); 13 Dec 2002 13:50:15 -0000
Received: from new-smtp2.ihug.com.au (203.109.250.28)
  by daedalus.apache.org with SMTP; 13 Dec 2002 13:50:15 -0000
Received: from p772-apx1.syd.ihug.com.au (expresso.localdomain)
 [203.173.143.10]
	by new-smtp2.ihug.com.au with esmtp (Exim 3.22 #1 (Debian))
	id 18MqCe-0000P8-00; Sat, 14 Dec 2002 00:50:08 +1100
Received: from jeff by expresso.localdomain with local (Exim 3.35 #1 (Debian))
	id 18MqCi-0003L1-00
	for <forrest-dev@xml.apache.org>; Sat, 14 Dec 2002 00:50:12 +1100
Date: Sat, 14 Dec 2002 00:50:11 +1100
From: Jeff Turner <jefft@apache.org>
To: forrest-dev@xml.apache.org
Subject: The Mythical Javadoc generator (Re: Conflict resolution)
Message-ID: <20021213135011.GF390@expresso.localdomain>
Mail-Followup-To: forrest-dev@xml.apache.org
References: <3DF74D13.9050507@apache.org> <3DF7A1A3.6010109@outerthought.org>
 <20021212062719.GB3340@expresso.localdomain> <3DF84620.6090406@apache.org>
 <20021212105639.GB6242@expresso.localdomain>
 <3DF88DCA.9050500@outerthought.org> <3DF8A2AC.2000500@apache.org>
 <20021212154534.GG3340@expresso.localdomain> <3DF8BDFF.9060109@apache.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3DF8BDFF.9060109@apache.org>
User-Agent: Mutt/1.4i
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

On Thu, Dec 12, 2002 at 05:49:03PM +0100, Nicola Ken Barozzi wrote:
...
> >>Everything must be underneath Cocoon, or we have a hybrid we cannot 
> >>easily control. What can't Cocoon do?
> >
> >Cocoon can't generate Javadocs, which is inherently a batch-processing
> >job.  
> 
> It can, it just needs a javadoc Generator.
> Give it a start dir, and it will generate a listing with the dir 
> Generator, generate all javadocs there, and get on by crawling the 
> directory links.

That is impossible.  Generating Javadocs is, as I said, "inherently a
batch-processing job".  Javadoc pages are highly hyperlinked, and the
Javadoc tool needs to have _everything_ loaded into memory, so it can
work out whether to write out, say, 'org.apache.foo.MyClass' or '<a
href="MyClass.html">MyClass</a>'.

Besides which, how long do you think it would take for Cocoon to invoke
Javadoc once for every single source file?

Cocoon is a doc generating tool.  Javadoc is a doc generating tool.  One
renders XML, the other renders Java files.  Trying to invoke one from the
other is... how do I put it politely... um, I'd better not even try :)


--Jeff