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:buildfirstTool
C:buildsecondTool
C:buildsettings.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.
11
Relative Paths
You could define some environment variables in windows. For linux users, this should feel familiar.
C:> SET VARIABLE_NAME="pathtodir"
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.
Gradle
Gradle is build automation evolved. Gradle can automate the building, testing, publishing, deployment and more of software packages or other types of projects such as generated static websites, generated documentation or indeed anything else.