JavaFX：打包后可编辑的配置文件 [英] JavaFX:Editable Configuration Files After Packaging

问题描述

我有一个JavaFX应用程序，我使用antBuild打包了该文件，以构建一个安装程序.exe文件，我的应用程序将一些配置文件放置在项目的根目录中，这样我就可以从项目的根目录加载它们以便将它们放置在.jar文件旁边并可以更改：

I've a JavaFX application that I packaged it using antBuild to build a single installer .exe file, my app have some configuration files that was placed in the root of the project this way i load them from the root of the project in order to they can be place beside the .jar file and could be changable:

        try {
        File base = null;
        try {
            base = new File(MainApp.class.getProtectionDomain().getCodeSource().getLocation().toURI())
                    .getParentFile();
        } catch (URISyntaxException e) {
            System.exit(0);
        }
        try {
            File configFile = new File(base, "config.properties");
        }

所以打包应用程序后，即使我手动将文件放在同一位置带有jar文件的应用程序再次无法识别它们并导致错误。

so after packaging the app even if I put the files manually in the same place with jar file, again the app can not recognize them and put into error.

那么正确的存储方式是什么以及在哪里存储某种配置文件，以及如何在安装过程中将它们添加到安装程序中以放置在正确的位置？

So what is the proper way to store and where to store some sort of config files and how to add them to the installer to put it to right place during installation?

推荐答案

如果您的应用程序捆绑为jar文件，则 MainApp.class.getProtectionDomain（）。getCodeSource（）。getLocation（）。toURI（）将返回 jar：方案URI。 文件带有 URI 假定它得到了文件： scheme URI，这就是为什么您在这里得到错误的原因。 （基本上，如果您的应用程序捆绑为jar文件，则 resource config.properties 根本不是文件，它是存档文件。）基本上没有（可靠的）方法来更新将应用程序捆绑在一起的jar文件的内容。

If your application is bundled as a jar file, then MainApp.class.getProtectionDomain().getCodeSource().getLocation().toURI() will return a jar: scheme URI. The constructor for File taking a URI assumes it gets a file: scheme URI, which is why you are getting an error here. (Basically, if your application is bundled as a jar file, the resource config.properties is not a file at all, its an entry in an archive file.) There's basically no (reliable) way to update the contents of the jar file bundling the application.

我通常采用的方法是捆绑默认配置将文件放入jar文件，并在用户文件系统上定义用于存储可编辑配置文件的路径。通常，这将相对于用户的主目录：

The way I usually approach this is to bundle the default configuration file into the jar file, and to define a path on the user file system that is used to store the editable config file. Usually this will be relative to the user's home directory:

Path configLocation = Paths.get(System.getProperty("user.home"), ".applicationName", "config.properties");

或类似的东西。

然后在启动您可以执行以下操作：

Then at startup you can do:

if (! Files.exists(configLocation)) {
    // create directory if needed
    if (! Files.exists(configLocation.getParent())) {
        Files.createDirectory(configLocation.getParent());
    }

    // extract default config from jar and copy to config location:

    try (
        BufferedReader in = new BufferedReader(new InputStreamReader(getClass().getResourceAsStream("/config.properties")));
        BufferedWriter out = Files.newBufferedWriter(configLocation);) {

        in.lines().forEach(line -> {
            out.append(line);
            out.newLine();
        });
    } catch (IOException exc) {
        // handle exception, e.g. log and warn user config could not be created
    }
}

Properties config = new Properties();
try (BufferedReader in = Files.newBufferedReader(configLocation)) {
    config.load(in);
} catch (IOException exc) {
    // handle exception...
}

因此，这将检查配置文件是否已存在。如果不是，它将从jar文件中提取默认配置，并将其内容复制到定义的位置。然后从定义的位置加载配置。因此，用户首次运行该应用程序时，它将使用默认配置。之后，用户可以编辑配置文件，随后它将使用编辑后的版本。当然，您可以根据需要创建一个UI来修改内容。这样做的一个好处是，如果用户做了一些使配置不可读的操作，则只需将其删除，即可再次使用默认设置。

So this checks to see if the config file already exists. If not, it extracts the default config from the jar file and copies its content to the defined location. Then it loads the config from the defined location. Thus the first time the user runs the application, it uses the default configuration. After that, the user can edit the config file and subsequently it will use the edited version. You can of course create a UI to modify the contents if you like. One bonus of this is that if the user does something to make the config unreadable, they can simply delete it and the default will be used again.

显然，这可以是项目符号可以更好地抵抗异常（例如处理目录由于某种原因不可写的情况，使配置文件的位置可由用户定义等），但这是我在这些情况下使用的基本结构。

Obviously this can be bullet-proofed against exceptions a little better (e.g. handle case where the directory is unwritable for some reason, make the config file location user-definable, etc) but that's the basic structure I use in these scenarios.

这篇关于JavaFX：打包后可编辑的配置文件的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！