Skip to end of metadata
Comment: Migrated to Confluence 4.0
Go to start of metadata

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

Research

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

Main

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

Plugins

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

Extensions
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)

Repository:

Where above geotools directory contains:

design/

replace with wiki and recent aaime uml diagrams?

 

 

doc/

Is this the website generation?

 

 

module/main

merged modules from the required list

module/mapinfo/

orphan

module/resources/

orphan

module/svgsupport

orphan

module/imagedatasource

orphan

module/vpf

orphan

module/utils

orphan

module/sample-data

orphan

module/legend

orphan

 

 

plugin/pickle

plugin disk serialization

plugin/arcsde

plugin arcsde access

plugin/geomedia

plugin arcsde access

plugin/gtopo30

plugin for GTOPO30 file support

plugin/mysql

plugin mysql access

plugin/oracle-spatial

plugin oracle access

plugin/postgis

plugin postgis access

plugin/shapefile

plugin for shapefile support

plugin/tiger

plugin tiger access

 

 

ext/graph

tree and graph creation/walker/visitor

ext/validation

validation framework used by geoserver

ext/demo

geotools-demos has moved here

 

 

buildlist.txt

 

geotools_checks.xml

 

build.properties

 

GT2Eclipse.java

 

maven.xml

 

navigation.vm

 

optionalList.txt

 

project.xml

root maven project file

README.txt

 

requiredList.txt

 

run-maven.xml

 

 

 

Module structure:

src/

source code for module

test/

junit tests for module

target/

not part of svn but is the structure seen during build

project.xml

maven build file

build.xml

would be nice as part of long term plan

Merge Branch

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

prep

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

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).

ext

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.

Labels
  • None

5 Comments

Hide/Show Comments

  1. May 18, 2004

    Martin Desruisseaux

    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

    • svn.geotools.org/geotools/trunk/geotools2/geotools-src/main/src/

    "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/

  2. May 18, 2004

    David Zwiers

    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.

  3. May 19, 2004

    James Macgill

    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.

  4. May 19, 2004

    Jody Garnett

    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 ...

    svn.geotools.org/geotools/trunk/geotools - core library specified by requiredList.txt
    svn.geotools.org/geotools/trunk/postgis - FactorySPI based plug-in
    svn.geotools.org/geotools/trunk/oracle - FactorySPI based plug-in
    svn.geotools.org/geotools/trunk/shapefile - FactorySPI based plug-in
    svn.geotools.org/geotools/trunk/graph - extention library built on geotools
    svn.geotools.org/geotools/trunk/validation - extention library built on geotools
    svn.geotools.org/geotools/trunk/demos
    svn.geotools.org/geoserver/trunk - related geotools baed WFS/WMS
    svn.geotools.org/udig/trunk - related geotools based client
    svn.geotools.org/spike/ians/trunk - spike hosting for IanS
    svn.geotools.org/spike/james/trunk - 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

  5. May 19, 2004

    Martin Desruisseaux

    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?