positioning files for use from both IDEs and JARs

On 3/2/07, Thomas L Roche <tlroche-r/[email protected]> wrote:
> I'm wondering how to position a file (either a .properties or a
> preferences XML) in filespace so as to satisfy all the following
> requirements: it can be
>
> * programmatically read from classes in an Eclipse project, e.g. when
>   launching a Java application
>
> * programmatically read from classes in a deployed JAR file
>
> * when deployed, read and written by a human outside the JAR. I.e. a
>   user could run the app, edit the .properties, re-run the app, etc,
>   without needing to open or rebuild the JAR.
>
> Details:
>
> I'm developing a plain-old command-line app in Eclipse. I want classes
> in the code to be able to read from a file when I launch the code, so
> I'm assuming I want the file to be in the project's filetree: assume
> that's rooted @
>
> laptop:/path/to/eclipse/myworkspace/myproject
>
> However I also want to be able to deploy the code in a JAR remotely,
> i.e. I should be able to do something like
>
> [laptop $] scp
> /path/to/eclipse/myworkspace/myproject/{prefs.xml,build/my.jar}
> remote:/path/to/deploy/
> [remote $] java -jar /path/to/deploy/my.jar
>
> I want users to be able to edit the file without having to hack the
> JAR. I.e. I want to support a usecase like
>
> [remote $] java -jar /path/to/deploy/my.jar
> [remote $] edit /path/to/deploy/prefs.xml
> [remote $] java -jar /path/to/deploy/my.jar
>
> I don't want to hafta specify the path to which the JAR must be
> deployed, but could do that if absolutely necessary. I'd also prefer
> to specify a JAR-relative path to the file: e.g. the user should be
> able to do something like
>
> Finally I want to be able to use the same API to load the file in both
> cases (whether running from eclipse or from deployed JAR).
>
> In neither case do I have control over where the user's JVM is
> located: probably the only things I can dictate are
>
> * the path to the file inside the Eclipse project
>
> * where the JAR is deployed
>
> * where the file is deployed. I'd prefer to specify that it be located
>   relative to the JAR, but could also give an absolute path (e.g.
>   /tmp/foo/bar.properties)
>
> I'm wondering, can I satisfy all the requirements? If so,
>
> 0 Where to locate the .properties file for both the eclipse project
>   and the deployed JAR?
>
> 1 Which API to use? I'm aware of several (besides the File* ones),
>   e.g.
>
> ClassLoader.getResourceAsStream
> ClassLoader.getSystemResourceAsStream
> Class.getResourceAsStream
> ResourceBundle.getBundle
>
> 2 Does the file just need to be on the classpath? If not, how to
>   specify the path to the file (or the file's URL) in the API call?
>
> If this can't be done, is there a next best alternative? (Short of
> passing all the properties on the commandline ?-)

Preferences is a good API, but not if you intend for users to edit the file.

Properties is probably still the most common.  You can do atleast
three things here.
1.  Do it the unix way (this works on windows too): /home/me/.myapp/my.props
new File(user.home, ".myapp/my.props");

2. Put it in the classpath.  For this you'll need a wrapper script,
which you'll probably have
anyway, to make the classpath a good, trusted place.
Class.getResourceAsStream("/my.props");

3. Put it in your app's conf dir.  Again, you would have a wrapper
script.  It could either pass
the conf dir location to the app via cli property or adjust the
working directory so you could use
a path relative to user.dir.

An alternative to Properties is using XML.  There are plenty of xml
binding APIs.
You're still going to have to locate it like a Properties file, but
your config will be automagically
loaded as objects instead of having to do all the reading and writing manually.

I'm sure there are several open source tools to do this too, like
apache commons configuration.

Personally...
If it were a server app, I would use a conf dir.
If it were a client app, I would use ~/.myapp
If it were a very simple config, I'd use Properties.
If it were complex or longer than say 20 lines, I'd start looking at jaxb.

--
Robert Dale