Refactor projects to separate core and plugins

[rfecher]

Here's an idea of how it could be laid out (some new projects added to give an idea of how the structure may grow).

├───.utility
├───analytics
│      ├───api
│      ├───mapreduce
│      ├───spark
├───core
│      ├───cli
│      ├───geotime
│      ├───index
│      ├───ingest
│      └───store
├───deploy
├───dev-resources
├───docs
├───examples
├───extensions
│      ├───datastores
│      │     ├───accumulo
│      │     ├───cassandra
│      │     ├───hbase
│      │     └───simplehdfs
│      └───formats
│           ├───geolife
│           ├───geotools-raster
│           ├───geotools-vector
│           ├───gpx
│           ├───stanag4607
│           ├───stanag4676
│           └───tdrive
├───services
│      ├───api
│      ├───client
│      │      ├───java
│      │      ├───javascript
│      │      └───ruby
│      └───webapp
└───test

[chrisbennight]

I think having a lightweight tools (or something like it) module that just has items that need to be referenced in multiple modules (in project and inherited) is a good idea. I'm thinking the eclipse formatter, and I'd like to do a findbugs configuration file, and a checkstyle configuration file.

With them being owned by an artifact it's easy to reference them from either the parent pom directory, or from within a child pom. If you don't do this then paths are terminally broken (you can either configure for invocation from parent directory, or module subdirectory, but not both).

See: http://mblanchette.github.io/maven-java-formatter-plugin/0.4/examples.html#Multimodule_Configuration for example

(i.e. I'd be tempted to move benchmark out of tools. What would you think of making a geowave-benchmark project? I don't think the benchmark needs to be in the core geowave project.)

[viggyprabhu]

Any particular reason why all the different projects are not maintained as a separate project code wise. The complete project can be built separately once in a while and released as Tarballs with all necessary jars for users but other wise, we can maintain projects separately. This will ensure very clear dependency separation and hierarchy. In such cases, atleast all the Plugin and tools projects can be maintained separately.

[rfecher]

We're thinking about pulling vagrant and benchmarks out of tools and into their own top-level projects. Otherwise, for now the modules are only useful through being tied together, so although there are not explicit dependencies, we will be using dependency injection to make the plugins useful. We think it would be the most cohesive for now to keep all of it under the same top-level project. If a specific plugin makes sense to work outside of the geowave project, it is definitely reasonable to consider on a case-by-case basis whether to develop a plugin within geowave. At some point plugins worked externally may want to consider being brought into geowave, the implication being that the plugin will be maintained as the baseline evolves. Other plugins that stay external to the baseline would be considered community modules that would imply others will maintain them as geowave evolves.

[rfecher]

more details associated with the PR