I found abc.properties.tmpl file in a java project.Which is similar to abc.properties file.I am not aware why it is important to keep tmpl file in project.
What is the use of this file?
Since you haven't mentioned which IDE environment you are using and where (in which folder of the project) you found this, there could be lots of possibilities:
1) This might have been generated or kept by the IDE environment being used e.g. NetBeans, Eclipse. I cannot remember if it's specific to HTML or just any templates that require property settings.
2) This might have been generated by some old application which hasn't been cleaned up.
As I said, you have to update the question with more relevant information (perhaps some screenshots/snippets) for a better answer.
The file might have been copied twice and renamed. Or the guy created the tmpl file as a backup while working on abc.properties file.
Not known, "tmpl" would be "template." When there are multiple locales, en_US, nl_NL, nl, nl_BE they all are placed in their own properties file, having the same keys but different language texts.
So the tmpl file might be for a new language, or when a key/text is added, so all other properties must be updated by doing a text diff.
My guess is, that the tmpl file does not need to be distributed. Check the produced jar, the build, references to tmpl.
Related
I want to edit a configuration file located in the current running jar.
Is there a way that allows modify directly this file or copy it from external?
You cannot modify the jar being run at runtime like Andreas suggested in the comments. I'll just put in a possible alternative to why you might need this in here, so this question doesn't show up in unanswered page.
Why?
When a jar is running (that is, it is being used by JVM), the file (archive >>file) is locked by the Operating System. When any file is locked (or marked as locked) it cannot be changed, in other words it is as good as a read-only file.
Why you might be in need of doing this.
Reason why usually people try to write into jar is that, they want a file which they want to use with absolute/relative path (with reference to jar file).
What option do we have in this case?
So, if this is your issue, you can make a directory in the jar's location and use it.
If your jar is at C:\Users\<Something>\Desktop\testDir\, then you create a directory 'conf' (C:\Users\<Something>\Desktop\testDir\conf\) in this place. You can write/create files in this directory and reference them from your code easily (with reference to the current working directory's path).
I am Java NOOB (seriously, about two weeks) and using IntelliJ.
My homework is to make a classes, which can process given images(which is in "input" folder), and store them into the "output" folder.
I really have no idea where to put those two folders(input, output) in.
My question is, which place should I put them in, without changing given directory written in template code.
Screenshot of my problem
By default, IntelliJ reads files from the top level directory of your project. For you, that is HW6. Place the input folder there.
See also Reading files with Intellij idea IDE.
In addition, it is possible to specify the "working directory in IntelliJ". You can specify where files are loaded from from the Run Configurations:
I'm create an application that is going to be run on Windows, Mac OX and Linux. I have a properties file storing user settings which need to be read and changed on the fly.
A JAR file is compressed and is not meant to be changed on the fly which means I should write to an external file.
I'm using :
new FileInputStream("database")
new FileOutputStream("database")
How do I create a URL which is going to be consistent throughout all three operating systems. The JAR is run as an application on the desktop and I would like the file to be stored somewhere discrete.
I've tried reading from a local file in the same package as this class :
this.getClass().getResourceAsStream("database")
This works however I can't seem to create an output stream to write to the same file but this would be breaking the rule of changing a JAR file on the fly.
There are plenty of good reasons for which you should not do this, off the top of my head:
GetResourceAsStream does not necessarily get the file from the JAR itself. You coincidentally got it from there because the Jar was the first or the only element in the class path.
Writing a file in your own Jar could break the JAR signature if you are going to sign it.
The database could need to be backed up; in this case you may want to back it up separate from the code (the code could be upgraded when restoring the database).
Hope this helps.
what I'd like to do is have files in a central location so that when I add people to my development team they can see the base version of these files but meanwhile have the ability for the rest of the team to work with their own local version.
I know I can just put the files in source-control (we use Tortoiese-SVN) and have my team change the local versions but I'd rather not as the exclamation mark signaling the file has been changed and needs to be committed, quite frankly, irritates me greatly.
I'll give two examples of what I mean:
We use quite a few build.xml files which relate to a single properties files which contains many definitions. Some of them can be different between team-members (mainly temporary working directories) and I'd like a new team-member to have the ability to get the properties file with the base config but change it if they wish.
Have the eclipse settings file in the SVN so that when a new team-member joins they can just retrieve the files from the server and have a base system running. If they wish they will be able to change some of these settings.
Thanks,
Ittai
What I have done in the past is having the file in a different location or with a different name inside the repository with an ignore real_file rule so that the subversion will not complain on the changed file, and have a small script that will copy the files to the concrete location.
For example, the .project Eclipse project file can be named eclipse-project-default in the repository. When a user downloads the local copy they run the script and they get a fresh .project (copy of eclipse-project-default) that they can change and will not show in the subversion status command.
The problem with this approach is that it is often easy to make a change to the file that should go to the central repository and is forgotten. The approach requires changing the actual file, and applying the same change to the config file that is actually uploaded. And then commit that change.
This really is a case for version control as you point out, but having said that I guess you could put a copy in a central file server and have them download it from their. You may even want to make this a read only file or directory.
If the status indicator bugs you that much you can set this file to be ignored by your version control system.
I have a java app, and the log4j.properties file is in src/com/my/path/props. On compile, it's copied into classes/com/my/path/props
The file is loaded via PropertyConfigurator.configureAndWatch(user.dir + "/classes/com/my/path/props/log4j.properties").
This all works fine normally, though it's not ideal because of using user.dir (but I do not know another way to reference a file relative to the "application's start directory"). The problem manifests when trying to run this application using an NT Service wrapper. When done this way, the user.dir changes from the application's root dir to wherever the NTService wrapper's exe file is.
My question is: What's the appropriate way to get a the String file path representation of the log4j.properties file in my classes/com/my/path/props/ directory? I realize this would completely break down if the props file were in a jar; but in this case, it's not and is simply a file on the file system.
I've tried new File(this.getClass().getClassLoader().getResource("com/my/path/props/log4j.properties").getURI()).getAbsolutePath(), but that fails because on production, the path to the file is actually a UNC path and consequently throws a "URI has an authority component" exception.
How do other people deal with this problem?
Thanks.
OK. So... you asked how other people deal with this problem. First, they do not leave it up to Eclipse for where files get placed. They choose where they want them, how they want to access them, and then have their build tool (which unless they are just playing around, should not be an IDE like Eclipse, but rather a dedicated build tool like Maven or Ant) where to place it.
The choice of where you want the file depends on what you want to do with it. If its simply a config file that will never be edited at runtime, you typically place it inside your JAR (which is another practice - applications are placed in one or more JARs, WARs, or EARs, not a classes directory). If the file is to be edited at runtime, which from your "watching" it appears to be the case, you typically put it in a config directory outside your JAR.
How you access it (from the filepath or the classpath) is another choice. Where possible, I favor accessing files from the classpath because it is more portable - and when in a JAR, pretty much required. If that doesn't make sense in your case, then choose a path other than "user.dir" if that is changing when you deploy. You can hard-code it, use an environment variable, a property, a config file, a command line argument, etc. to set the actual path.
Always choose where things go and how you access them. Don't let your tools choose for you. It will make your life easier :-)
I took singleshot's advice and kept the properties files out of src and instead in a separate directory which I added to the classpath. In retrospect, this was indeed boneheaded to have configured it the way I did originally.
From there, my problem was getting a File from a URL. I ended up finding what I needed in Commons IO FileUtils, with its toFile(URL) method.
The code ended up looking like this:
private URL maintenanceConfigPath = this.getClass().getClassLoader().getResource("MaintenanceConfig.properties");
....
File f = FileUtils.toFile(maintenanceConfigPath);
....
Again, thanks to all for your feedback and for pointing me down a path that got me towards an answer