How to move away from hardcoded paths in our build processes

We have a set of Java tools that are built and run locally. Whenever one of the devs commits a change, everyone else (including non-developers) need to do an update and build the tools.

Everyone uses windows machines so whoever designed the build processes decided to place everything in a folder called C:\build and dump all of the class files in the appropriate folders. For example, the folder might look something like

C:\build\firstTool\
C:\build\secondTool\
C:\build\settings.ini


We also have a huge library folder where all the jars go, and it's placed here

C:\lib\


As a result, many classes are simply assuming this is where the files are going to be stored and have hardcoded paths everywhere.

What can I do to clean things up? I don't want users to have to build tools, nor do I want them to have to update any checked out repos on their end.

Personally, I think developers should be the ones maintaining releases.

• Using a build tool such as Ant would make this a moot point. At the very least, use relative directories so as long as the build structure is checked out into one location, it works. – user22815 Mar 4 '14 at 18:36
• That is how the current build process works. We are using Ant, and everything is stored under C:\build. This doesn't really seem like the proper way to do it since there are references in our code directly to C:\build\... So what happens if we decided to change where we store our files? All of the code is broken and we have to update it. I could make it so that we use constants so that I only need to update one line, but it still seems kind of questionable. – MxLDevs Mar 4 '14 at 18:38
• Properly written Ant scripts should be relocatable to other project roots. It sounds like maybe your other tools need to use the current working directory rather than hard-coded directories. Or accept command-line parameters which can be passed in from Ant. Even better, write custom Ant tasks and pass in child tags such as <fileset>. – user22815 Mar 4 '14 at 18:47
• Your guesses are probably correct. Our projects are very simple, but the processes seem really lazy. Copy paste everywhere, hardcoded paths, etc. I've been considering moving to Maven but I want to at least clean things up first with Ant to get an idea how that might be done. – MxLDevs Mar 4 '14 at 18:53
• If you want to move to Maven, do not bother cleaning anything up now. Maven will necessarily involve redoing everything from scratch anyway, which is an opportunity for a clean break. Just do your research and understand it thoroughly ahead of time: a poorly done Maven build will cause no end of headaches. – user22815 Mar 4 '14 at 19:03

Relative Paths

You could define some environment variables in windows. For linux users, this should feel familiar.

C:\> SET VARIABLE_NAME="path\to\dir"


sets the environment variable VARIABLE_NAME to that path. Windows will then replace %VARIABLE_NAME% with whatever you put in the quotes, whether it's valid or not. (If it's not, it'll throw an error.) For example, you could list the contents of the path using dir as follows:

C:\> dir %VARIABLE_NAME%


You could create a .bat file that will set these environment variables and then call the appropriate build script. Environment variables are only valid for the life of the script calling them.

But that's really not what you should be doing. You should be using a build tool.

Build Tools

Build tools are going to allow you to have a lot more control over your builds, managing dependencies and project lifecycles. You should consider moving to one to try and ease some of the build related pains you're feeling now. Currently there are 3 big names in the build community. I've included links to the project pages, with a brief description below.

Maven

Apache Maven is a software project management and comprehension tool. Based on the concept of a project object model (POM), Maven can manage a project's build, reporting and documentation from a central piece of information

Ant

Apache Ant is a Java library and command-line tool whose mission is to drive processes described in build files as targets and extension points dependent upon each other. The main known usage of Ant is the build of Java applications. Ant supplies a number of built-in tasks allowing to compile, assemble, test and run Java applications. Ant can also be used effectively to build non Java applications, for instance C or C++ applications. More generally, Ant can be used to pilot any type of process which can be described in terms of targets and tasks.