Hello Simone
Your analysis is right. For the Java 6 issue, the plan is to create a mercurial
clone porting the code to Java 5 when the referencing module will be done. This
clone could also contains a "legacy" module for deprecated classes removed from
geotidy but still in use in other geotools/geoserver modules.
The roadmap is:
- utilities (done)
- metadata (all GT 2.x done - more JAXB-related later)
- referencing (in progress)
- coverage
- statefull renderer
referencing to be done in November. The port to Java 5 could start at that
point. For other modules, we will see as things progress.
Integration with other GeoTools 2.x modules is not on this roadmap since it
depends on what the community wish. The topic may be better discussed when the
community will have a real geotidy-referencing module they can look at before to
make their choice.
This is an unilateral move partially because we though that our objectives is in
minority (correctness more important than visualization, javadoc everywhere...).
But we try to do that in a way that let peoples move in other directions if they
wish. The switch to a distributed versionning system (Mercurial) is part of this
plan. We are developping geotidy on a "geomatys" repository, not an "osgeo" one
(or any other official repository) and I would not suggest to move to such osgeo
repository before a year or so. I think we need that much time in order to see
if some consensus emerges about what "tidy" could means.
Regards,
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
