The module restructuring is interesting; in general I like the layout of "plugins" "library" etc... it lets people know what they are getting into ... however I understand that build structure may be non optimal product packaging.
Can we retire the existing module after this proposal is accepted? The only public contract we have here is with the DataStoreFinder; I would like client code to be able to update smoothly if they used DataStoreFinder (and if they have used a constructor or something directly I am okay breaking). This proposal also does not actually say very much about what is going on: - you say there is no public api from the client point of view - fair enough - should we consider the public api (and the contract you have) with implementors? - do not make public class OracleDataStore (it should be package visible to be created by an OracleDataStoreFactory? - can we fold this into the existing oracle plugin; and simply make the factory return the new implementation? - there is no documentation changes? can we have an update the the JDBC DataStore page (http://docs.codehaus.org/display/GEOTDOC/JDBCDataStore+Developers+Guide) even if all you say is to use the new class using OracleDataStore as an example In short - this may be a good idea but from the proposal I cannot tell what the idea is. Jody ------------------------------------------------------------------------- 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
