[osmosis-dev] API 0.6 and unique keys

[Brett Henderson]

On Tue, Feb 3, 2009 at 1:21 AM, Jochen Topf <jochen at remote.org> wrote:

> On Mon, Feb 02, 2009 at 11:08:31PM +1100, Brett Henderson wrote:
> > Jochen Topf wrote:
> >> On Mon, Feb 02, 2009 at 09:39:03PM +1100, Brett Henderson wrote:
> >>
> >>> Anyway, it looks fine to me.  I'll check it in in the next few
> >>> minutes unless something distracts me.
> >>>
> >>
> >> Migrate test failes now...
> >>
> > Interesting.  It passed when I ran the full suite of tests prior to
> > checking in.  I'll check on Linux in a few minutes ... sometimes line
> > endings can screw it up.
>
> I found the problem. For some reason the migrate test triggered the JPF
> magic and it seems it was trying to read some plugin from my
> ~/.openstreetmap directory. That failed with a null pointer exception.
> After removing that dir, it works fine. I have no idea why the migration
> test triggered this but not the other tests.


The reason for the difference in behaviour is how the tests are written.
Some tests just test individual classes.  But others such as the migration
test invoke the entire osmosis pipeline and therefore also invoke the JPF
functionality.


>
> I can also use the -p plugin mechanism now. I haven't tested the JPF
> magic because I don't need it really, but my problems there were
> probably also due to some wrong jar file lying around there or so.
>
> I am not sure any more that this JPF magic is the right way to go. At
> least not in this current form. We would at least need some kind of
> versioning mechanism so that I can get a proper message: "Found plugin
> xyz which conflicts bla bla" instead of just giving a null pointer
> exception. I rarely use Osmosis from the command line, normally I have
> scripts calling it, so I don't mind having some extra command line
> options.


The fact that we're getting a NullPointerException is bad.  Any
NullPointerException is a bug.  It may be just that we need to re-factor the
JPF code to be more explicit about what steps it's doing so that you can
tell which plugin is being loaded when it fails.

But as to the JPF functionality, I'm quite happy if you don't use it.  The
JPF plugin support is currently building on the old plugin support anyway.
Both mechanisms are using the PluginLoader interface as a way of registering
new tasks.  The old plugin uses the explicit -p command line option but
doesn't help with managing the classpath, the JPF support avoids the end
user having to explicitly register plugins and can (I think) deal with extra
jar dependencies.

If I was writing a plugin for my own use I wouldn't bother with JPF
initially because it's much easier to debug a plugin without it (or it seems
that way at the moment).  I'd use JPF if I was distributing plugins to end
users though and it should be great for that purpose.  I'm tempted to try
separating out the pgsql tasks into a plugin to see how easy this really is.

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