svn – Best way to test on different environments? – Education Career Blog

I am working on a Java project which needs to work on both Mac OS X and Windows. There are many variables which store paths to various resources and files.

Is the best way to deal with them, putting them all in a separate class (say, Constants) and maintain two branches for the file in SVN ?

Update : It is not just an issue of path separator character (forward vs backward slash). The directory structure is different for both systems. On Mac, I keep my resources in various directories. Say, images somewhere, log files somewhere. On Windows, I might use totally different directories. It is not necessary for all the directories to be part of one tree (i.e. they are not in different directories under one main directory called ‘resources’ or something). This is not necessarily a bad programming practice. Sometimes you need to access system files or system-wide common directories and you just can’t put them under one supreme directory

,

Have you looked into using a properties file instead? Apache commons config should be cross-platform and it intelligently handles where the properties files should be.

This way you only have one build but the configuration files are operating system specific, should be considerably less to maintain, build, and test.

,

Not sure what exactly the problem is. (Java is designed to be fairly platform agnostic.)

Take a look at java.io.File static constant pathSeparator, pathSeparatorChar, and separator, and separatorChar. If you have a constant tree structure for how you are organizing your resources (i.e. in dot format: resources.data.test.woof.txt), you can use the File.separatorChar instead of the ‘.’ and you have your system specific path.

Also, don’t neglect the very informative System.getProperty() method.

That should be sufficient to walk any path on any FS.

,

If you’re using JDK 1.4 or higher, and the user needs to be able to change these paths, you can use the built-in Preferences API to store/update them. If not, you could define constants for each OS, and call System.getProperty(os.name) to figure out which one to use. This should still prevent you from having to have separate builds per platform.

Leave a Comment