Plugins don't work on OSX?

[klos]

Hi, I was trying to install the pmsencoder on my mac and realised that it doesn't work because the plugins directory seems to be ignored on a mac. can someone confirm this???

[cabbey]

They can be made to work. But it's a PITA.

1. make sure you're using at least a 1.20 build.
2. right click on the app and choose show package contents.
3. find under there the plugins directory at Contents/Resources/Java/plugins/
4. copy all the jar files for your plugin into there.
5. find the Info.plist file in /Contents/
6. open it in plist editor
7. find the classpath item
8. add an entry to it for each jar file you copied in
9. save the plist
10. start the app as normal.

Here's a screen shot of what my info plist looked like for adding ONE plugin, the smugmug-pms3 plugin.


Everytime you get a new binary, or update a plugin you'll have to redo that.

[chocolateboy]

Vote for (i.e. star) the patch if you want this fixed:

https://code.google.com/p/ps3mediaserve ... ail?id=766

[cabbey]

Hmmm... did you actually load a plugin via that? what does that turn the classpath in the info.plist into? I wasn't able to get it to accept jars from any form of wild card.

[chocolateboy]

Hmmm... did you actually load a plugin via that? what does that turn the classpath in the info.plist into? I wasn't able to get it to accept jars from any form of wild card.

I don't have a Mac or access to one, so the patch was based purely on the JarBundler documentation (and source code). Feel free to submit a better patch.

Note: the Unix runtime classpath (in PMS.sh) is:

Code: Select all

$PMS_HOME/update.jar:$PMS_HOME/pms.jar:$PMS_HOME/plugins/:$PMS_HOME/plugins/*

- but the Ant Pattern wildcards used by JarBundler extend the classpath syntax.

[cabbey]

Yeah, so the problem with that is that you're only going to list the plugins that already exist in the directory at bundle creation time since the ** is parsed at build time. So far as I've been able to determine, there is no good solution for getting dynamically added jars into the classpath for a bundled application... if there was, I woulda submitted a patch originally instead of the above set of directions. Your patch should still be good for the update.jar though.

[chocolateboy]

Yeah, so the problem with that is that you're only going to list the plugins that already exist in the directory at bundle creation time since the ** is parsed at build time.

Ah. Thanks for letting me know.

So far as I've been able to determine, there is no good solution for getting dynamically added jars into the classpath for a bundled application...

Nothing in, say, Vuze or Limewire? This issue must have arisen before.

Surely, if nothing else works, you could just add a -classpath option to vmoptions e.g.

Code: Select all

<jarbundler
    vmoptions="... -classpath '$JAVAROOT/update.jar:$JAVAROOT/plugins:$JAVAROOT/plugins/*' -jar"
    ...
/>


[chocolateboy]

I've updated the patch as per the above. Could you try it?

[cabbey]

So far as I've been able to determine, there is no good solution for getting dynamically added jars into the classpath for a bundled application...

Nothing in, say, Vuze or Limewire? This issue must have arisen before.

Ah, I'd forgotten that Azereus had dynamic plugins. Nothing obvious in their info.plist I'll have to dig into their sources.

hours later... I need a mental bath, that source tree is a MESS. But I found it. They're dynamically altering the classpath within their application using a URLClassLoader. Basically finding all the jars in the plugins tree (they have to deal with versioning in there too, so it's finding the newest version of them all) and building a url loader that uses them. Also some bug avoidance logic around chaining URLClassLoaders. So it could be done, but it's hardly a mac unique item that's buried in packaging... would end up touching core parts of how the program works everywhere.

Surely, if nothing else works, you could just add a -classpath option to vmoptions e.g.

Code: Select all

<jarbundler
    vmoptions="... -classpath '$JAVAROOT/update.jar:$JAVAROOT/plugins:$JAVAROOT/plugins/*' -jar"
    ...
/>


Nope. The classpath items in the plist replace the -classpath options on that line.

[chocolateboy]

Ah, I'd forgotten that Azereus had dynamic plugins.

Limewire does too, apparently. I'll take a look at it if I get a chance, but feel free to beat me to it.

They're dynamically altering the classpath within their application using a URLClassLoader.

I feared as much.

Nope. The classpath items in the plist replace the -classpath options on that line.

For crying out loud! How about -cp?