Application Support directory to classpath

[Hendrik Schreiber]

Hey Michael,

FWIW, I have been using https://bitbucket.org/infinitekind/appbundler as packager/launcher for a while now. It passes a couple of additional environment variables to the JVM:

	• LibraryDirectory
	• DocumentsDirectory
	• CachesDirectory
	• ApplicationSupportDirectory
	• SandboxEnabled (the String true or false)

Not sure what javapackager does. Perhaps this is helpful for you.

-hendrik

> On Mar 12, 2016, at 12:00, Michael Hall <mik3hall at gmail.com> wrote:
> 
>> On Mar 11, 2016, at 3:47 AM, Michael Hall <mik3hall at gmail.com> wrote:
>> 
>>> 
>> 
>> Maybe someone else can answer the question of whether or not this has been considered for sandboxed java applications so that you actually do get something different for these properties that is usable?
> 
> Given no one has tried answering this I would either assume sandboxed settings aren’t different or people who know if they are different aren’t following the list anymore. 
> 
> It doesn’t seem all that bad an idea to me. With applications getting more complex having different possible settings for some of these properties could make sense. Say signed and sandboxed versus not MAS targeted could have different user.dir settings. 
> 
> Meanwhile, since I am not currently MAS targeted I will see what I can do with Application Support, although that is really not all that different from using user.home/user.dir. 
> 
> javapackager user.dir I think had user.dir set to the app path itself. Useful for read access of your own app files, but not for storing data assuming you are in the Application directory with no write permissions. Again since the Apple jvm’s (user.dir was always the app's directory as I remember) I think this setting has changed a couple of times. javapackager may of changed again I vaguely remember.
> 
> My last couple tries with javapackager didn’t successfully get me valid application bundles at all, but it wasn’t anything I needed critically.   
> 
> I will take a look at your links.
> 
> Thanks.
> 
> Michael Hall
> 
> 
>