2016-02-29 38 views
0

后,我一直认为我是用antBuild建立一个单一的安装程序.exe文件打包JavaFX应用程序,我的应用程序有一个是这样,我加载放置在项目的根一些配置文件他们从项目,以便根到他们可以.jar文件旁边的地方,可能是多变的:JavaFX的:可编辑配置文件包装

 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文件后,该应用程序再次无法识别它们并且发生错误。


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

回答

2

如果您的应用程序打包为一个jar文件,然后MainApp.class.getProtectionDomain().getCodeSource().getLocation().toURI()会返回一个jar:方案URI。 constructor for File taking a URI假设它获得file: scheme URI,这就是您在这里遇到错误的原因。 (基本上,如果你的应用程序打包为一个jar文件中,资源config.properties不是一个文件,同时,其在存档文件中的一个条目。)还有基本上没有(可靠)的方式来更新JAR文件捆绑的内容应用程序。

我通常处理这个问题的方法是捆绑缺省配置文件到jar文件,并定义用于存储可编辑的配置文件中的用户的文件系统上的路径。通常这将相对于用户的主目录:

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

或类似的东西。

然后在启动时,你可以这样做:

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来修改内容。这样做的一个好处是,如果用户做了一些事情来使配置不可读,他们可以简单地删除它,并且默认将被再次使用。

很明显,这可以防止异常更好一些(例如,处理由于某种原因导致目录不可写入的情况,使配置文件位置可由用户定义等等),但这是我在这些场景中使用的基本结构。

+0

你会如何处理应用程序的更新?删除旧的或合并配置? – Inge

+1

本质上我们合并它们。在我们的应用程序中,“加载属性”步骤比我在此处显示的要复杂得多。如果文件不存在,则每个单独的属性都会分配一个默认值。在程序退出时,我们明确写出了属性,包括默认值。 (我们也有在大多数的应用程序的GUI配置屏幕,这样的配置可以在运行时更改。)所以,如果一个新版本引入了新的配置属性,它透明地从旧的配置获得它的缺省值文件它第一次运行。 –

+0

信息的好解决方案 – Inge