GeoTools : Module Merge

So we have the go ahead to slice and dice the module structure that has been used by Geotools for the 2.0 stream.


To provide a guideline for this merge process we are sorting modules into three camps:

  • main: core geotools2 library
  • plugins: modules that intergrate at runtime with the whole via a Plugin or Facotry interface
  • extentions: independent libraries built on top of the main

To acomplish this we:

  • Released Modules: split the existing modules up based on release
  • Unrelased Modules: asked for public feedback on unreleased modules
  • submitied conservative, crazy and wild plans to the list/wiki for review

Merge Goals

Goals for this merge process:

  • stop the insanity
  • provide a structure that we can maintain Going Forward
  • provide a migration path for plugins/extensions
  • ensure that existing CVS branches like grid-exp, fid-exp can be merged back into the result


We intendend to group these core modules together into one source tree similar in style to the one already deployed.


Short Term: placed in a plugin directory next to module
Long Term: move into separte projects besides geotools

Short Term: placed in a ext directory next to module
Long Term: move into separte projects besides geotools

The directory "ext" is recomended so the directory can capture both demos,validation,graph. Name is similar to the ext directory in a jre. Plus it handles extension and extra.

The gap between short and long term plans is limited by our ability to hack our maven build process. While it is temping to move to the long terms solution until the build process is in place it would just ensure the orphaning process.

The Great Module Round Up

  • Everything will stay the same in terms of the build enviornment based on maven.xml
  • Half the modules are merged together into a single main module.
  • The demos module is merged in just like a normal module.
  • the geotools-src is renamed to module
  • The spikes projects are removed
  • geotools2 is renamed to geotools (could shorten to gt)


Where above geotools directory contains:


replace with wiki and recent aaime uml diagrams?




Is this the website generation?




merged modules from the required list




















plugin disk serialization


plugin arcsde access


plugin arcsde access


plugin for GTOPO30 file support


plugin mysql access


plugin oracle access


plugin postgis access


plugin for shapefile support


plugin tiger access




tree and graph creation/walker/visitor


validation framework used by geoserver


geotools-demos has moved here














root maven project file









Module structure:


source code for module


junit tests for module


not part of svn but is the structure seen during build


maven build file


would be nice as part of long term plan

Merge Branch

Log of actions to acomplish the above on the merge branch.


svn mv geotools2 gt
svn mv gt/docs gt/doc
svn mv gt/spike spike
svn mv gt/geotools-demos gt/ext
svn mv gt/geotools-src gt/module
svn mkdir gt/plugin


svn mv gt/module/arcgrid gt/plugin/arcgrid
svn mv gt/module/arcsde gt/plugin/arcsde
svn mv gt/module/geomediea gt/plugin/geomediea
svn mv gt/module/gtopo30 gt/plugin/gtopo30
svn mv gt/module/mysql gt/plugin/mysql
svn mv gt/module/oracle-spatial gt/plugin/oracle-spatial
svn mv gt/module/postgis gt/plugin/postgis
svn mv gt/module/shapefile gt/plugin/shapefile
svn mv gt/module/tiger gt/plugin/tiger

Pickle was not transfered to the plugin folder (intended for caching).


svn mv gt/module/graph gt/ext/graph
svn mv gt/module/validation gt/ext/validation
svn mv gt/module/j2se-demos gt/ext/demo

Merge Main

svn mv gt/module/core gt/module/main
svn mv gt/module/main/tests/unit gt/module/main/test
svn rm gt/module/main/tests  

svn mv gt/module/defaultcore/tests/unit gt/module/main/test

(warning) I am stuck at this last mv command (it won't let me play) - do I have to move files over one at a time?
(warning) I am not sure how to merge sdocbook folders as their are name conflicts.


Agree with:

  • Moving spike/* to their own project
  • Renaming 'geotools2' as 'geotools'
  • Renaming 'geotools-src' as 'src' or 'sources'

A would love to simplify the tree structure. Currently, it looks like


"geotools" appears 4 times!!!! And "src" appears 2 times. The proposal in "Would be nice II" seems... nice (smile) Maybe I would suggest to rename "src" as "sources" and drop "unit" since are our tests are based on JUnit:

  • foo/src/ --> foo/sources/
  • foo/tests/unit/ --> foo/tests/
Posted by desruisseaux at May 18, 2004 10:52

I would have prefered to see all of the dataStores lumped together under one common dir, similar to main. This would provide all the required information as we could use package structure to distinguish the dataStores ... and allow us to refactor and share code where appropriate within the data Stores.

Although I understand that some people may want to keep the code seperated for binary distributrion, I would argue that you could achieve the same result by placing collections of packages together in appropriate jars.

Similarily I would also like to see the 'extras' placed together in a utility folder (validation + graph), as these two modules are closely related (direct dependencies from validation to graph), and once again they can be packaged seperately.

Posted by polio at May 18, 2004 13:34

I'm not particularly keen on the lumping idea from the stand point of tracking dependencies. By keeping the data stores seperate it is easy to track which ones use which jars, putting them all together would cause problems like:

unit tests failing for people without ALL of the data stores being available
compilation failing for people wihtout proprietary jars (e.g. Oracle jars that we can't distribute - though mocks could be used...)

Keeping them seperated also makes life easier for new developers (and safer for us) as we can 'let them lose' on a specific module without fear that they will stray into code that they should not be playing with.

We can still refactor and share in most IDEs even if the files are not in a single directory - I use our free licence to RefactorIT on our current file structure. I do agree that we need something for shared code and we may need additional plugins for abstract or template data stores.

Posted by jmacgill at May 19, 2004 11:11

The jar file in the repository is not that bad (svn does binary diffs). In terms of looking like something I would expect to download ... - core library specified by requiredList.txt - FactorySPI based plug-in - FactorySPI based plug-in - FactorySPI based plug-in - extention library built on geotools - extention library built on geotools - related geotools baed WFS/WMS - related geotools based client - spike hosting for IanS - spike hosting for james

Where each represents a complete module/project with:

  • src
  • tests
  • target
  • lib
  • build.xml file for ant
  • .project/.classpath for Eclipse
Posted by jive at May 19, 2004 12:12

I would like to avoid JAR files in SVN too... Its look like ibiblio's job to me.

From the above list, my proposal would be:

  • src
  • tests
  • build.xml file for ant (maybe)

"target" sound like the compilation result. If so, then I think that putting it in SVN is generally not recommended. And ".project/.classpath" may be to Eclipse specific. For a Netbeans users, its look like distractive. Some users using different Eclipse version may have compatibility problem, and some other users may want their own setting for some reason. Having the Eclipse setting in SVN could means that a custom Eclipse setting may conflict with the setting provided on SVN, or be commited accidentally?

Posted by desruisseaux at May 19, 2004 12:29