For example:
MyApp is a web app that contains a properties file (server.properties) that describes config data (e.g. server names) for the app. In the development phase
D.
Load the properties in the jar. Then create a new Properties using the jar-ed properties as the defaults. Then load from outside the jar. This allows select customization of properties.
I develop J2EE applications using Spring. I was running around the same problem quite a long time and then found a solution. My problem was to specify the database properties in a properties file outside the war file that I deploy. The solution I found to this is to use the PropertyPlaceholderConfigurer and specify the location property to locate your system location as this,
This was quite simple and it worked just fine !
I'd go with D.
Try to load the properties files from outside the .jar then, if that fails, load the properties built into the jar.
This lets you push out a "ready made" configuration with each build (also reduces the complexity of a deployment, if by just one file), while also making overriding configurations possible and reasonably simple.
Frequently it is a criteria that code should be migrated UNCHANGED from test to production. This implies that you may not edit embedded configuation files. Also you may end in a situation where you need to change a deployed configuration - which frequently is very cumbersome. Hence, we leave the configuraiton outside the jars.
For Java EE applications consider JNDI or a property file in the classpath.
I have a web application where the configuration is retreived from a neighbor web application simply to separate the two. That turned out to be much easier.
I've asked a similar question. We haven't figured it all out yet. But we're looking into URL Resources. Where the property-file is read directly from SVN. No need update anything other than the property file.
It depends. If the properties file contains data that is intended to be changed by the user of your application or library, than it should reside outside.
If it contains data that is static and you created the properties files just to avoid coding the values in the sourcecode or if the files are localized strings, I'd leave them in the jar. At least because a properties file invites people to change values ;)