I would like to write down my proposal for GeoTools 3. Do we already have a
wiki
page for that?
My infrastructure wish list (I'm not yet venturing in API or design wish list):
Goal
-----------------------------------------------------------
Make a cathedral emerge from the bazar.
Code repository
-----------------------------------------------------------
Mercurial hosted on OSGEO. I known that Mercurial vs Subversion is a debated
topic, but more I think about it more I believe that it would have helped us to
avoid issues like JAXB annotations while the community is not ready, etc. We
could have commited the annotations on a Geomatys mercurial clone and
eventually
merged to the OSGEO repository later. GeoServer could have local modifications
in their own clone without the pressure to merge to the OSGEO repository if
they
feel that are not ready, etc.
No unsupported modules
-----------------------------------------------------------
Side effect of using a distributed versioning system: the unsupported directory
would not exists at all. GeoTools 3 would be about stable and supported modules
only. Experimental modules can be commited to Mercurial clones, or to GeoTools
2.
Raise quality
-----------------------------------------------------------
No code allowed on the OSGEO mercurial without accurate javadoc for all fields
and methods. Apparently minor details like serialVersionUID, equals(Object),
hashCode() and other API contract must be handled properly. Intellectual
property must be perfectly clear (all major contributors have signed agreement
-
uncertain code has been replaced).
Remember: if a code do no meet all conditions, it can live on any mercurial
clone with almost no inconvenient until we merge it to OSGEO, and the merge is
much easier than SVN.
Simplier Maven
-----------------------------------------------------------
Module names match exactly directory names (with prefix). No profiles, because
no unsupported modules to exclude from the build and no special case for
OnlineTest (the later are replaced by JUnit 4 "assume" features). Plugins
trimmed down and some custom plugins (e.g. our custom javacc) replaced by
standard ones.
In GeoTools 2, we still unable to get the site deployed on a daily basis. We
have spent many hours hacking the pom.xml today and yesterday for getting the
today reports deployed. Every deploy is uncertain because our Maven build is
very weird. In comparaison GeoAPI is deployed daily like a charm. I would like
the same charm for GeoTools 3.
Target Java 6
-----------------------------------------------------------
(I'm thinking JAXB, but also new JDBC API for handling arrays in databases, a
few new functions in java.lang.Math, new Arrays.copy methods and improved
handling of @Override annotation and parameterized types by the compiler). I do
not expect GeoTools 3 to be useable for GeoServer before two years. By that
time, Java 6 may be widely distributed enough.
Thats the first item that popup from my mind. I could elaborate more on a wiki.
Do we open such a page? If so, in which section?
Martin
-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
