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
_______________________________________________ osmosis-dev mailing list osmosis-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/osmosis-dev
