Hey all,
I feel dumb for asking this because it because it seems so fundamental
but I'm discovering that things like
org.geotools.factory.FactoryRegistry
and
org.geotools.resources*
are really meant as internal resources for the library, not for users of
the library.
Is there a clear distinction between the API which should be used by
third party users of the library and the API available to geotool
developers (whats in the javadocs)?
If so, could we either or both
1) present a verbal list or a logic to the separation that any
new user could understand.
2) generate a set of javadocs for third party users? (yes, I
realize this cannot happen while *none* of the javadocs are
being generated.
Is the package module/api a complete description of the api's which
should be used for module/main or are there also some classes in
module/main which should be used?
On Wed, 2006-04-19 at 09:07 +0200, Jody Garnett wrote:
>
> The point is I never want to see the "ShapefileDataStore" class used in
> any example, they should be limited
> to the actual geotools API.
^^^^^^^^^^^^^^^^^^^
What is this? Does it exist?
On Fri, 2006-04-21 at 16:36 +0200, Jody Garnett wrote:
>
> API
> ===
> Lets talk about interfaces, abstractions and modeling power:
> - "geoapi" contains interfaces that have been through formal review, we
> are working on adopting several higher level ideas (coverage, feature,
> expression and style and maybe Geometry) but for 2.2.x we are limited to
> CRS and friends
> - module/api - these are APIs that have been through QA and are
> consistent (if not always complete), the goal of this module is to be
> *empty* and to make use of GeoAPI interfaces as they are made available
> and approved.
> - any other API (like rendering) has not been reviewed by me yet - so I
> am not sure if it makes consistent use of factories for example
This is more of a logic for why things are the way they are, *not* a
helpful description of how to define what users should use. We all
realize that only some of GeoAPI gets used, that we rely on JTS for the
geometries, that (some?all?) of the api for module/main is in
module/api, and that there is some other api which should be available
in the other packages like rendering. However, I'd really like to have a
formal list, perhaps as a set of packages.
A clearly defined API is a critical element of being a library.
Furthermore, I need this if I am going to be able to write useful docs
both as one of the pieces of the docs and as a map to presenting the
different parts of the library.
But maybe i'm simply confused or perhaps this is a jira issue?
thanks,
adrian
-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
