[osmosis-dev] Plugins

[Brett Henderson]

Frederik Ramm wrote:
> Hi,
>
> Brett Henderson wrote:
>> On a semi-related issue, do these jar file names have to match exactly?
>
> And on a distantly-related issue, is it really necessary to have a 
> plugin mechanism where you have write XML files and encapsulate stuff 
> in zip files and use all this JPF overhead?
>
> I know JOSM is not known for its elegant architecture but in JOSM, all 
> you have to do to create a plugin is extend the Plugin class, put the 
> jar file in the plugins directory, and add the name of the jar file to 
> a config option, a process that has been understood and mastered by 
> countless people who weren't Java buffs.
>
> In JOSM, writing a plugin is only marginally more complex than writing 
> the class and integrating it into JOSM directly. What I see here does 
> not exactly encourage me to write plugins for Osmosis; it seems that 
> it is going to be much less hassle simply adding an action to Osmosis 
> proper than encapsulating the same in a plugin.
>
> Maybe it looks different for people who had prior JPF exposure. What 
> are the advantages of using this over just loading the jar file and 
> instantiating the class like JOSM does it?
If this turns out to be too complicated and error prone then we'll 
discard it, but I'd like to give it a chance and see how it turns out.  
I'm hoping that creating a JPF plugin isn't much harder than in JOSM but 
I haven't looked at one yet to know for sure.  I'm hoping it's as simple as:
1. Create your new tasks and supporting classes.
2. Implement the PluginLoader interface which will allow osmosis to 
register your task names.
3. Compile all the code into a standard jar file.
4. Modify an existing boilerplate plugin.xml file to point to your 
plugin loader class.
5. Copy the jar and plugin.xml file into a zip file.

Most plugins shouldn't require additional support jars and so on so 
don't need to get into the gory details of JPF.  Most of the work should 
be writing your tasks.  If we can create a boilerplate eclipse project 
that allows you to write code straight away and including an ant script 
that generates the plugin then it should be straightforward ... maybe :-)

What I'm hoping JPF gives "for free" is the ability for somebody to 
package up a plugin that allows you to write data to some arcane 
database with a bunch of supporting libraries (eg. Hibernate, Spring, 
etc) without requiring the end user to manage the library dependencies 
manually.  Allowing libraries to run within their own classloader and 
avoid conflicts with libraries from other tasks is very useful if it 
works.  How are plugin library dependencies handled in JOSM or isn't it 
usually an issue?

Again, I haven't looked at or created a working plugin yet so don't 
really know how this works yet.

Brett