Hello Mickael
Michael Bedward a écrit :
> At this stage I don't think I understand enough about the different
> strands that are going on to make an informed decision.
I will try to give some hints. Of course they reflect only my point of view, and
I may realize in a few months that I need to change that view.
* Geotidy is an attempt to reduce redundancy, hide a bit more internal
mechanic (so user focus more on API), sometime reorganize the public
API (e.g. moved collection implementations in their own org.geotools.
util.collection package - but I try to keep the amount of such changes
not too high and I provide a tool for helping developers to migrate),
remove deprecated methods, fix most javadoc and javac warnings, add
documentation, all the above in the hope to make the library more
understandable to users.
* At this point Geotidy contains utilities, metadata and referencing
(in progress) modules. Later it will contains coverage, statefull
renderer and widgets as well. They are all modules that I initiated,
but got substential contributions from others (Rueben Shulz, Jan Jerzek,
Simone, Andrea Aime, Johan Sorel...). Nevertheless except for the widget
module (and to a less extent the renderer as modified by Johan), I have
a rather clear picture of those modules and their weakness which would
be nice to fix in geotidy (except for the "ease of use" part, where
external advice is better since the original author often doesn't see
what other may find unintuitive).
* When the referencing module will be ready in geotidy, I suggest that
Geotools drops their own metadata and referencing modules, and replace
them by a dependency toward the geotidy modules. The rational is that
I'm not maintaining Geotools referencing module anymore except for
trivial patchs and geoapi compatibility, and I don't see who else in
the current Geotools contributor could take over it.
* Geotidy targets Java 6, which is not acceptable for Geotools.
Consequently a backport to Java 5 will be necessary. Additional
changes may be needed; for example Geotools may wish to reintroduce
(at least temporarily) some deprecated classes or methods I removed.
I commited myself to help in this task, by setting up a repository
for the Java 5 backport, providing tools (in the form of Ant scripts,
etc.) for helping in the backport to Java 5, and initiate the work.
* Above paragraph is based on the assumption that Geotools would
accept this approach. The decision is up to the PMC.
* If the above approach is accepted, Johan's widget would be like any
Geotools module, except that it would be hosted on an other repository
targeting Java 6. If Java 6 is acceptable for you, you should be able
to use it like a GeoTools module. If it is not and if considered worthly,
we would need to backport this module to Java 5 as well.
Martin
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
