Mailing-List: contact dev-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Ant Developers List" <dev@ant.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
Date: Wed, 9 Mar 2005 05:32:54 -0500
From: jfuller@ruminate.co.uk
Message-Id: <200503091032.j29AWs309260@server1.ruminate.co.uk>
Subject: Re: Ant documentation
To: "Ant Developers List" <dev@ant.apache.org>
Cc: 
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="bound1110364374"

--bound1110364374
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

jfuller@ruminate.co.uk wrote ..
> > > The main problem here is that there is no unique answer 8-)
> > > 
> > > My guess is the following is more or less true:
> > > 
> > > (1) autogenerate as much of the docs as possible from the Java sources.
> 
> yes within reason
 
opps hit the send button a little too quickly,

to me the only question now, to harmonise generation of documentation from java source code is to decide if XDoclet generates a native xdoc or limited docbook format....to be honest doing either is an option.

IMHO, its interesting to think of a task having 

- embedded documentation in java source code
- task markup which could override, amend, or provide full documentation
- which can be related to a library markup perhaps controlled by ant.apache.org, though not necc.

whereby its own build script can generate its own individual documentation (be it docbook or xdoc) and scale up to fit into Apache Ant build documentation system.

--Jim Fuller


--bound1110364374
Content-Type: text/plain; charset=us-ascii

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
--bound1110364374--