On 12/22/05, Martin Desruisseaux <[EMAIL PROTECTED]> wrote:
Jody Garnett a écrit :
>>> I have just downloaded GT2.2.M2, but the JavaDoc seems to be broken!
>>> For example I miss the index.html.
>>
>> We noticed this problem when we created the 2.2 build with Maven 1.
>> Even with -Xmx1024M, we have been unable to avoid an OutOfMemoryError
>> during javadoc generation. I plan to try to fix that with the Maven 2
>> build. Not sure when it will be ready however...
>
> Perhaps we could build *just* the api and main modules? Or even just api
I have generated a new set of javadoc using an Ant script (because Maven
1 produces an OutOfMemoryError, and Maven 2 do not yet produces a
cross-module javadoc). Temporary link here (to be moved elsewhere later):
http://www.espace.ird.nc/~usespace/javadoc/geotools/
Request for opinions:
* Any change proposal for the group content? (i.e. the packages to
put in the "Data Stores" group, the packages to put in the "XML
and derivatives (GML, SVG)" group, etc.)
* Any change to the group names?
* Any change to the group order (which ones to put first)?
* Any packages or modules that should be excluded?
For developers:
* Should I commit the ant script on SVN as a gt/build-javadoc.xml
file (at the root of every modules)?
Sounds good here.
* Should we put the javadoc on a different server?
* I would like to define a @module tag to be added in every class
description. This @module tag would just contains the name of the
module that contains this class. I can make a Maven 2 plugin that
put automatically the module name after the @module tag (it would
modify the source). The goal is to have some hint in the javadoc
about where a class can be found, since a single package is
sometime splitted in many modules. Any agreement / objection?
I think this is a good idea. Without looking at your build file, I have a few ideas. Is it posible to complete this during the compile cycle only (copy the src, augment the src , ... ), leaving a 'clean' svn repository?Ccould we take this one step farther, and include the intended target binary too (jar file name) ... it should be accessable when the build is happening.
* javadoc generation produces 2382 warnings. A little bit of cleaning
would be appreciated. (I already cleaned a lot in the referencing
and coverage modules). For example if a method has a @return tag
with no description, then I suggest to not put any @return tag at
all. Just removing empty @return tags would solve many javadoc
warnings.
My Eclipse install has quite a few more than that ... it all depends on the compiler's settings. But yes, I do agree we should look at cleaning up the javadocs for public api.
David
Martin.
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&opclick
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
