Java Build Systems, Part 1: What they do
Two recent posts on the java-weblog circuit spurred me to motion:
Maven Adoption Curve (Alex Miller, coworker at MetaMatrix)
Maven and Ivy (Ryan Senior, coworker at BJC)
I was trying to think of the ideal build system. I won’t pretend that I’m going to get there in this post. Instead, I’ll enumerate what we do every day and what we need from a build system so as to start thinking about the ideal system.
So, to the brainstorming. Here’s what we do in the regular process of our osgi bundle development:
- Obtain dependencies
- Compile java source
- Compile javafx source
- Generate metadata / configuration data
- Make jar files
- Upload jar files to central repository
- Upload jar files to deployment location
- Update remote (OBR) xml file with information about uploaded jar
- Generate reports about the quality of the source (clover, PMD, checkstyle, etc)
- check out from CVS / source control
- check in to CVS / source control
- tag CVS / source control
- manage versions and releases
I’m sure there are more. Obviously, under web development, you’d deal with wars and their deployment. We have ssh tasks to run code on the server. We even have some install/run stuff that works pretty well.
You may have guessed we use maven. Maven is so close, but just not there. It is frustrating, performs a lot of magic, and just falls down in annoying ways. We have gotten it to do all of the above, some of it is just not pretty.
Next episode, I’ll go into Maven and what it does well and what it does poorly. Stay tuned!