[osmosis-dev] Project Restructure

[Brett Henderson]

Hi All,

I just created a "breakup" branch.  I had several hours in an airport
without much to do so started experimenting with a new way of packaging
osmosis.

One problem I have with the current "single project" approach is that every
time a new feature is added, a whole bunch of new libraries need to be added
and the distribution is starting to get fairly large.  It's also reached the
limit of what I can maintain myself given the limited time I have to spend
on it.  I'm hesitant to allow too many new tasks to be added because it gets
hard to ensure that they're maintained properly and they're hard to remove
once they're in there.

So far the branch has the following projects:
- core - Most of the existing project.
- apidb - All of the apidb tasks (with postgresql dependencies), depends on
core.
- pgsnapshot - All of the pgsql tasks (with postgresql and postgis
dependencies), depends on core.
- package - Depends on the above three projects and adds the launch scripts
and config files.

The apidb and pgsnapshot tasks are no longer loaded directly via the
TaskRegistrar class, but instead defined via a osmosis-plugins.conf file in
the package project which specifies their plugin class names.  The idea is
that all tasks will be factored out of the core and into plugins which are
bundled into the main distribution so that the end user doesn't see any
difference.

It doesn't compile yet due to some class dependency issues in the
replication code, but I'll sort that out next.  I aim to move the vast
majority of existing tasks out into plugin projects.  The plugins will
loosely be aligned to the task groups defined on the detailed usage page on
the wiki.
http://wiki.openstreetmap.org/wiki/Osmosis/Detailed_Usage

I'm hoping this will allow people to develop new plugins and incorporate
them into the main build and distribution without too much effort, and lower
the current barrier to entry by eliminating the need to pass my code review
to make it into core.  By keeping them out of the core, I can focus on core
and the tasks I maintain and rely on others to keep their tasks up to date.
If they fall behind and aren't maintained they can be removed from the build
and distribution by changing a couple of config files instead of having to
delete them entirely.  The existing plugin methods (ie. raw plugins
specified with -p on command line, and JPF plugins) will both continue to
work so external plugins can still be developed if desired.

Once I get it working I'll create a simple No-Op plugin task that provides
an example of how the plugin projects are created.

So far it looks like it should work fairly well without adding too much
complexity.  The ant builds for each project are becoming much smaller and
more well defined which should be a good thing.

Let me know if you see any major issues with this approach.

Cheers,
Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/osmosis-dev/attachments/20100616/d345e262/attachment.html>