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.
Best Answer
Relative Paths
You could define some environment variables in windows. For linux users, this should feel familiar.
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: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
Ant
Gradle