From: Rob H. <rob...@vf...> - 2002-05-24 15:48:35
|
James, I am sure that you are already thinking of something along these lines, but with the explosion of GeoTools2 code as of late, it would be really helpful to me if there was some sort of on-line, auto-generated (nightly) API documents, similar to those for GeoTools1. I am guessing that this would be helpful to others as well. I would be happy to assist in writing the Ant task to do this. Any interest? Rob Hranac Vision for New York 377 Broadway NY, NY 10013 tel: 212.219.6052 fax: 212.219.6006 eml: rob...@vf... web: www.vfny.org |
From: Martin D. <mar...@te...> - 2002-05-24 16:06:32
|
Hello > [...] it would be really > helpful to me if there was some sort of on-line, auto-generated > (nightly) API documents, similar to those for GeoTools1. Of course I fully agree!! I have no experience with Ant, but there is my proposal for javadoc option: javadoc -sourcepath {SOURCE_DIRECTORY} -d {DEST_DIRECTORY} @gtbuild/javadoc-options.txt Where "javadoc-options.txt" is a file containing the following: -quiet -source 1.4 -nodeprecated -noqualifier all -docfilessubdirs -windowtitle "Geotools 2 API" -doctitle "Geotools 2 API" -header "Geotools 2 API" -overview overview.html -link http://java.sun.com/j2se/1.4/docs/api -link http://java.sun.com/products/java-media/3D/forDevelopers/j3dapi -link http://geotools.sourceforge.net/javadoc/opengis -group "Coordinate Transformation Services (CSS)" "org.geotools.pt:org.geotools.cs:org.geotools.ct" -group "Grid Coverages Services (GCS)" "org.geotools.cv:org.geotools.gc:org.geotools.gp" -group "Utilities" "org.geotools.io:org.geotools.util:org.geotools.units" -subpackages org.geotools -exclude org.geotools.resources ------------------------------------------------- In the example above, "http://geotools.sourceforge.net/javadoc/opengis" should point to some place in the Geotools 2 with the OpenGIS JavaDoc, and "overview.html" should be some file somewhere giving an overview of the whole Geotools 2 project. There is more "-group" options to add for other modules too. Martin. |
From: Cameron S. <csh...@bi...> - 2002-05-24 20:37:49
|
I'd also like to see a high level explaination of the interdependance between modules. I'm thinking about a UML diagram of modules, and 2 line description of each module, along with link to detailed module docs. I figure this should be in the developers guide. On Saturday 25 May 2002 01:51, you wrote: > James, > > I am sure that you are already thinking of something along these lines, > but with the explosion of GeoTools2 code as of late, it would be really > helpful to me if there was some sort of on-line, auto-generated > (nightly) API documents, similar to those for GeoTools1. I am guessing > that this would be helpful to others as well. I would be happy to > assist in writing the Ant task to do this. Any interest? > > Rob Hranac > Vision for New York > 377 Broadway > NY, NY 10013 > tel: 212.219.6052 > fax: 212.219.6006 > eml: rob...@vf... > web: www.vfny.org > > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > _______________________________________________ > Geotools-devel mailing list > Geo...@li... > https://lists.sourceforge.net/lists/listinfo/geotools-devel |
From: James M. <j.m...@ge...> - 2002-05-24 22:13:45
|
At 06:40 25/05/2002 +1000, Cameron Shorter wrote: >I'd also like to see a high level explaination of the interdependance between >modules. I'm thinking about a UML diagram of modules, and 2 line description >of each module, along with link to detailed module docs. >I figure this should be in the developers guide. I was editing such a document earlier today :) I hadn't considered a UML overview, for now I'll post it as it as soon as its ready. Ideally this is another document that should be being generated automatically from XML module descriptors. James -- James Macgill Center for Computational Geography Spell Checker (c) Creative Spelling inc (aka my dyslexic brain) http://www.geotools.org the open source java mapping toolkit. |
From: James M. <j.m...@ge...> - 2002-05-24 22:08:50
|
At 11:51 24/05/2002 -0400, Rob Hranac wrote: >James, > >I am sure that you are already thinking of something along these lines, >but with the explosion of GeoTools2 code as of late, it would be really >helpful to me if there was some sort of on-line, auto-generated >(nightly) API documents, similar to those for GeoTools1. I am guessing >that this would be helpful to others as well. I would be happy to >assist in writing the Ant task to do this. Any interest? I think its a given that this is a good idea, feel free to make a start on the Ant script additions. If you can end up with the javadocs in a predictable directory in the CVS I can add the cron jobs to the sourceforge site to make sure they get posted regularly. There is an issue of whether we produce a single JavaDoc set for all modules (which whilst complete may be overwhelming) or a separate build for each module in which only docs for the modules code and the modules it depended on were built. Any suggestions? Perhaps we should aim to do both... James -- James Macgill Center for Computational Geography Spell Checker (c) Creative Spelling inc (aka my dyslexic brain) http://www.geotools.org the open source java mapping toolkit. |
From: Martin D. <mar...@te...> - 2002-05-25 09:35:49
|
Hello > There is an issue of whether we produce a single JavaDoc set for all > modules (which whilst complete may be overwhelming) or a separate build > for each module in which only docs for the modules code and the modules > it depended on were built. > > Any suggestions? Perhaps we should aim to do both... I vote for a single JavaDoc (in order to help to get a bigger picture), but in which each packages are regrouped by module (using the -group option). The following is an example of a JavaDoc with three groups (modules): http://seagis.sourceforge.net/javadoc/seagis/overview-summary.html Of course, we can do both ways too. But I would like to see at least this way... Martin. |