Hi all, On Sun, 2015-11-15 at 16:59 -0800, tony mancill wrote: > I agree that a patch would be the cleanest approach. Perhaps you could > get away with simply a wrapper script that sets some system properties? > (I haven't looked at JPF very closely yet.) Keep in mind I'm not a proper Java developer, so I might be missing quite a few things. Java Pathfinder as a JVM defines quite a few properties (e.g., a scheduling choice generator class), including some that are software verification-specific. By default, these are specified in jpf.properties in the code base root directory. The main JAR file is expecting this info to be in one of search paths in the increasing order of importance: 1) Java classpath (where it should be in a file jpf.properties), 2) ~/.jpf/site.properties, 3) jpf.properties in the current directory. I see how this is done in JPF and I can either put the /usr/share/java directory to the classpath and put jpf.properties to /usr/share/java/jpf.properties, or I can easily patch Java Pathfinder such that it searches for jpf.properties somewhere else, e.g. in /etc/jpf/. What do you suggest to do? My hunch is it shouldn't be /usr/share/java/jpf.properties as there are only JAR files in /usr/share/java. Also, it shouldn't be ~/.jpf/site.properties as that is user-specific. > You should also consider whether a JPF user might want to use both the > modules provided by Debian and search for modules configured in the > site.properties file. The question there will be the search order. Ok, I'll keep this in mind. For the time being I want to get it working for a single system-wide installation. > In general, anything you can do to ensure that the package works "out of > the box" without manual user configuration (but while still supporting > local configuration if desired) is the preferred approach. Thanks for explaining this! -- Regards, Marko http://dimjasevic.net/marko
Attachment:
signature.asc
Description: This is a digitally signed message part