I'm starting the process of packaging a Java-based application for
MacOS, and I'm wondering what the "preferred" way of organizing
jars, resources, etc. would be if you have more than just a
standalone application bundle. In my case, the application includes
some network services that run out of the same jars as the
application itself. My options would seem to be:
1) Install everything into /Applications/MyApp. Thus I'd have /
Applications/MyApp/MyApp.app, /Applications/MyApp/lib/
wholebunchofjars.jar, etc. The service configurations would go in /
Library/LaunchDaemons. Upside: if the user moves the .app folder,
things will still run, since the app and services will know to look
in /Applications/MyApp/lib.
2) Include everything except the launchd plist files in /
Applications/MyApp.app. This looks neater, but if the user moves the
app bundle, the services will no longer run
3) Create a framework in /Library/Frameworks/MyApp.framework, and
put all the libraries in there. Services and app will all look for
their jars in the framework directory, and I can even version things
if I want.
#3 would seem to be the best option, although it would be a bit more
work to maintain (possibly). Is it legit to have a "framework" even
if it's really just a place for me to dump my jars and such?
A framework is just a bundle like any other, but it's primary mission
in life is to provide a known anchor point for native applications to
link against it's symbols, and provide headers to the compiler. I
don't think it would be "illegitimate" to make a framework with no
headers or Mach-O binary - but I just don't think I've ever seen it
done.
It might make sense to just create a "MySharedResources.bundle" and
put that in /Library/Application Support, if you've already resigned
to using the Mac OS X Installer. You can keep your jars in "Contents/
Resources/Java", and version it using the bundle's Info.plist. The
Installer will keep every bundle coherent, and prevent downgrading any
particular bundle's version.
Hope this helps,
Mike Swingler
Java Runtime Engineer
Apple Inc.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden
