I work on a Java project with a suggested structure (separate src folders for java files and resource files).
After moving the message / text related properties files to that folder, the externalize strings mechanism in Eclipse does not work as before.
Usually when hovering over the key string in a getString(“”) call, the tooltip showed the content of the properties file with the default locale. That has been extremely helpful for me personally. It seems as if that feature only works if the properties file is in the same source folder as the Java code that manages the BUNDLE_NAME stuff.
Can I make a strong case for moving the properties file back to the src-folder, or should they be kept separate from the java source files? Anything else that I can try to get the feature to work again with the new structure?
4
No, its not ok to put property files into the source directory. Some build environments could get rather unhappy with such a structure. While yes, it may work, and the source directory may be in the class path for you in Eclipse, the best option is to have the resources in a separate directory.
Think of the build process. This is typically ‘build all the files from the source directory and put the resulting class files in another directory (target, or dist)’. When there are property files (and other resources) mixed in there, the build gets more complex having to select another set of files to get copied to the build directory.
A much easier approach is to have source in one spot and resources in another. This is actually the preferred directory structure that maven requires (with some directories left out):
src/main/java src/main/resources src/main/webapp src/test/java src/test/resources
This allows the tests (JUnit or TestNG) to be able to use a separate set of resources rather than the main resources and makes testing much easier.
Likewise, the webapp directory is handled specially when building a .war file.
Keeping the properties separate makes for an easier build process, a cleaner identification of the files that are needed to be part of the class path, and an easier test environment for overriding those files that are part of the main class path for testing.
7
Don’t let your tools (IDEs, frameworks, build tools, etc) dictate how you organise your code. Don’t put your properties files where eclipse wants them and don’t put them where your packaging tool would like them.
Organise your code such that it is obvious what your application does and so that code and resources are as close to the things they depend on as possible. If you want to change feature foo it you should be able to find it and all of its dependencies close together not intermingled with bar. You shouldn’t have to search or rely on your ide to find what you’re looking for.
If your tools don’t support this approach then change your tools.
1