This article describes the directory structure and command shell environment configuration I use on my development machine to help manage tools, source code and dependent libraries.
On Windows I keep all my development tools and source code under c:\dev. On Linux I use the same layout under $HOME/dev/
Inside the “dev” folder I have the following sub-directories:
/tools – contains executable application, tools and utilities, like Eclipse, DbVisualizer, Tomcat, Maven, HSQLDB, etc. I only place tools here that you can install manually simply by unzipping them (for example, Ecipse, Maven, Tomcat). For the tools or applications don’t ship in a zip file but only come with installers (for example, Java, Oracle, TortoiseSVN) – I let these tools install to their default locations (for example, under “C:\Program Files” or “/usr/local/”).
/lib – contains binary distributions of 3rd-party libraries and documentation, like GWT, JUnit, SpringFramework, Hibernate, etc. These days this directory is actually pretty empty – since I now mostly rely on the Maven to download 3rd party libraries and store it in the local Maven repository. However, it is still sometimes useful or necessary to have the documentation and examples handy.
/os – contains source code for 3rd-party Open Source libraries and tools. I also use it as a sandbox for unpacking and executing 3rd party sample code. The entries here are usually transient.
For example, on Windows I have:
I also place my own source code projects directly under “dev”, for example:
BTW, “spikes” is a nice “catch all” place for trying new things out before moving them into “real” projects. Even though “spikes” only contains throwaway or proof-of-concept code, I tend to commit the contents to a SVN repository. Some people use the term “sandbox” instead of “spikes”.
Shell Environment Configuration
To set up my environment variables I create a command file in the “dev” folder – usually called “setenv.cmd” on Winows and “setenv.sh” on Linux. The file sets up the path, environment variables, and on Linux it also sets up aliases.
On Windows I find it far more convenient to manage the environment settings through a command file rather than going through the Control Panel (System > Advanced > User Profiles > Environment Variables) dialog. It’s also very useful if to set your environment through batch files if you sometimes need to run a different versions of a tool (for example, if you use Java 6 for new projects but sometimes have to run Java 1.4 for legacy projects).
This is an example Windows setenv.cmd file: