Matthias Basler wrote:
I wondered if it is me being too stupid or the API being poorly designed or
Eclipse Java tools being buggy. So I did a test.
So before we continue w/ this conversation I gotta confirm what you are
testing?
- geotools/branches/fm
- geoapi/pending
It sounds like you are testing something other then the above? Back in
september I compiled a report on geoapi, geotools, jump, deegree, gml3,
and learned a bit from each and we put together a proposal (which you
can see in the geotools RnD page).
Since that time Bryce has produced a couple great reports, and pointed
out some simplifications I could make, the result of that is now in
geoapi pending and is being used by the geoserver team as they work
towards the first 2.3 milestone release.
A) Original API.
----------------
I created a new Java project, added the original "geoapi-tiger.jar",
downloaded from GeoAPI as depencency and tried to create an implementation
with method stubs.
Result:
Follwing four methods occurred twice with different type signatures:
(The signatures being <Feature> and <?>.
- public boolean containsAll(Collection c)
- public boolean addAll(Collection c)
- public boolean removeAll(Collection c)
- public boolean retainAll(Collection c)
After removing the generics (as shown above) all name clashes were resolved.
The result is, not type safe any more, but at least it works.
So I scrapped the geoapi-2.0-tiger api, it was technically wrong in a
couple areas. Can you try reviewing the following javadocs?
- http://geoapi.sourceforge.net/pending/javadoc/index.html
B Modified API
--------------
Now I repeated the above with the "geoapi-2.0-tiger.jar" downloaded from
lists.refractions.net/geotools/geoapi/jars/. This is the one I use in
projects that contain Geotools code.
You can do that, but geotools does not implement any of the geoapi
feature / feature collection interfaces indeed like you I don't recomend it.
I have NO IDEA what I could do ...
... except declare the modified geoapi-2.0-tiger.jar as unimplementable
... or use the geoapi jar without the tiger, which I would not like.
Any help is appreciated.
You may wish to send your origional review to the GeoAPI list? Add a
comment on the RnD page comparing feature models.
Good research :-) Now that you know where we are heading any feedback
would be great! The earlier we find problems the better.
Jody
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel