ImporImage Plugin

[Frank]

hello,
I wanted to ask why the "ImportImage Plugin" got deleted from the wikiplugin-list.

[bastiK]

Hi, I tried to contact you before, so I'm glad we can resolve the problems now and the plugin can be published. :)

In the first binary you checked in, the Manifest file looked like this:

Manifest-Version: 1.0
Ant-Version: Apache Ant 1.7.1
Created-By: 14.0-b16 (Sun Microsystems Inc.)
Author: Christoph Beekmans, Fabian Kowitz, Anna Robaszkiewicz, Oliver 
 Kuhn, Martin Ulitzny
Plugin-Class: org.openstreetmap.josm.plugins.ImageImportPlugin.ImageIm
 portPlugin
Plugin-Date: ${version.entry.commit.date}
Plugin-Description: Plugin for importing spatial referenced images
Plugin-Link:  -- will soon be added -- 
Plugin-Mainversion: 1.0
Plugin-Version: ${version.entry.commit.revision}
Class-Path: .

You need proper values for Plugin-Mainversion and Plugin-Version, otherwise the plugin mechanism will not work.

Make sure, you always have the most recent JOSM core checked out and compiled, when building your plugin. The first version you added was a little out of date, Dirk Stöcker fixed it in [o23187]. (Apart from whitespace stuff there were also real code changes.)

Have a look at DevelopersGuide/DevelopingPlugins, most important points:

• do not commit code changes and *.jar at the same time
• if there are changes in JOSM core and the plugin needs to be adjusted, set the Plugin-Mainversion accordingly

It should be possible now, to publish without problems.

Can you create an account on josm.openstreetmap.org? This way, we can assign user bug reports to you. It would be good to have an email address of one of the authors, so we can contact you, just in case...

(see #5447, ​josm-dev post)

Best, Sebastian

[bastiK]

See #5485, I think you need to specify each jar file separated by space, but I'm not sure as there is no other plugin using this feature at the moment.

[anonymous]

Great, seems to be working fine now.
Can you link the Plugin to
​http://wiki.openstreetmap.org/wiki/JOSM/Plugins/ImportImagePlugin ?

[stoecker]

Set the "Plugin-Link" entry in manifest for webpage link.

P.S. I doubt that your "Class-Path" method works. All other plugins copy the jar's directly into the josm plugin, as the class-path probably only works for stuff already installed on target system.

[bastiK]

Replying to stoecker:

P.S. I doubt that your "Class-Path" method works. All other plugins copy the jar's directly into the josm plugin, as the class-path probably only works for stuff already installed on target system.

They copy the jar's into the plugin folder and use a custom class loader and some hacks.

[bastiK]

@user123/Frank/anonymous/Gruppe 16/Fabian:

Can we use the same method to provide large set of projections for JOSM? If the answer is yes, it might be a good idea to split the ImportImage plugin into a Geotools plugin and the ImportImage part. This should also reduce traffic as it is 10 MiB in download size.

[Gruppe 16]

Hi!

Sorry for the problem concerning the contact.
We will fix that.

@user123/Frank/anonymous/Gruppe 16/Fabian:

Can we use the same method to provide large set of projections for JOSM? If the answer is yes, it might be a good idea to split the ImportImage plugin into a Geotools plugin and the ImportImage part. This should also reduce traffic as it is 10 MiB in download size.

In general this should be possible. In that case the plugin maybe has to be adjusted for the particular Geotools version. We experienced some difficulties when using different GT versions (such as (transcendent) dependencies or method signatures). But for the usage inside JOSM one static version should be sufficient.

The traffic issue remains when someone wants to make use of our plugin, but of course the benefit for JOSM is higher. We also thought about a download task which downloads the required libs from maven repositories, but not all libs are available with the respective version.

P.S. I doubt that your "Class-Path" method works. All other plugins copy the jar's directly into the josm plugin, as the class-path probably only works for stuff already installed on target system.

They copy the jar's into the plugin folder and use a custom class loader and some hacks.

In fact this issue has cost a lot of time. The problem was that unpacking all libs into the plugin jar produced errors when using JavaAdvancedImaging when trying to initialize the service provider which contain the imgaging operations. Also we were not sure because of license stuff.
Another way was leaving the library jars as jars and copy them into the jar, so called "jar in jar". But the needed "jar in jar" - classloader was not applicable for this because this method ALSO copies all jars into a temp directory and THEN loads the jars. Also this method didn't run proper.

After all we created a custom classloader (we also had problems fetching the layer icon from the jar using "Class.getResource(...)" method).

In fact the entry in the MANIFEST file (Class-Path) has no usage.

Greetings,
Christoph

[stoecker]

BTW Should we include the new classloader into JOSM when it improves the plugin handling?

[bastiK]

We need reflection to load the plugins. They add the jar in such a way that you can normally import the classes as if they were in the classpath. Do we need this? After all, we have to assume there are no plugins at all, whereas they use the jar files as libraries.

[stoecker]

Basically I mean we should probably add a way to carry jar-libraries inside a plugin and specify them in manifest. JOSM core should then take care for making them available.

[bastiK]

Yes, might be useful. But note that there is no clean or straightforward way to do this: You have to override some private field and hope it is handled gracefully. (See ImageImport code)

However there are a lot of applications that rely on this hack, so it will probably also work in future (Oracle) Java versions. :)

[bastiK]

(If you have a startup script it is of course no problem to change the class path before running the jvm.)