What do you use for a complex build process? [clos

Question

I am trying to revamp our build process, which is currently a gigantic Ant build.xml that calls into other ant build files and executes several Java classes to perform more complex logic that would be impossible/scary to attemp in Ant.

Background:

• experience in Java and Ant, some Groovy
• Windows platforms

Goals:

• run as a combination of command line cron and when a servlet is posted to
• as simplified as possible, fewest languages and bouncing between techs

I need higher level logical power that a language like Java provides and Ant is pretty easy and we use the filtering to override default properties files for different clients. Mostly I'm wondering if there is something other than Ant/Java that people use.

Answer 1

Maven is really good choice to do large builds...in the majority of the cases where it doesn't work is very simple. The people misunderstand the concepts of Maven. If your are working with the "maven way" you will end up with smaller modules which gives you a better architecture in your software. On the other hand things like Hudson will support you in reducing build times by using Maven, cause Hudson supports to build only changed modules which is not supported by any other build tool. The problem with Maven is to learn and understand the concepts of Maven for example the structure of a project(folders etc.) or only a single artifact etc. The build-cycle will support you in different areas: compiling, packaging, deployment and release which is not supported by other tools (only if you implement it by hand...I've wrote many large Ant scripts to reach this)...Other problem like changes over the time are caused by ignoring the best practice and pin pointing versions which are used.

Answer 2

I use Ant, taking advantage of its macro feature. If you layout your project in a consistent mannner, you can eliminate a lot of the duplication by writing macros.

I've been building up an Antlib containing macros and custom tasks that I reuse across multiple projects.

Alternatively, some people swear by Maven. Other people just swear about Maven.

Answer 3

I use Maven, not just for build, I also use their release/dist plugin.

In a pair of commands I can have code that was in a source control to build, package and release.

The release plugin handles updating the version numbers, dist handles how to put everything together and zip it.

Ant looks hard when compared to Maven. Sure there is a learning curve with Maven, but reading a pom.xml is far easier than reading a build.xml.

Maven needs to be far less verbose.

Answer 4

Stick with Ant since you're building Java. I've mixed Ant/SCons for some JNI work, but in general I'd stay with Ant especially since you've got an existing build setup in Ant. Porting to Maven will be like shoving a square peg through a wall with no holes.

Embrace your custom Java logic for any and consider writing proper Ant tasks instead of executing external Java code. I solved some very complex parts of our build process by simply extending Ant to do exactly what I needed, ex. managing icon resources for a large gui project or injected subversion information directly info jar manifests (thank you SVNKit)

Answer 5

I have to add to these one solution that I find I can't live without ... its called Hudson. It only takes a few seconds to setup and you can usually get away with most of whatever your existing ANT files are already doing.

Additionally, Hudson provides a great way to "cron" builds, execute test cases, and generate "artifacts" (e.g. build products) in a way that anyone can download.

It is hard to capture all that it can do for you ... so just try it out ... you will no be disappointed.

Answer 6

I'd go with Ant any day of the week.

It's not perfect; XML is very verbose and implementing any logic at all is almost impossible, but even the most junior engineer on the team can at least understand what the ant file is doing within a day.

Complex logic can be refactored using java and integrated in ant, if you so wish. Ant gives you all the power of java:)

Dependency resolution is difficult no matter what system you use. With ant, the best solutions seem to be either a lib directory in which all your jars are stored, or an internal web server from which the libraries are copied at build time.

I also have some experience with both Maven 1 and Maven 2. That experience left me with the feeling that Maven is awesome for hobby projects, but can have complications for software you need to maintain over time.

I see two important problems with Maven:

• Any dependency you import using Maven may change over time without you knowing it, resulting in weird problems.
• You import the licenses of not only the software you import directly using Maven, but also the licenses used by the libraries which are indirectly imported

In short, I dislike the fact that the build depends on the time it is started. That can be a true problem when producing a bugfix release a year after the production release.

These problems can of course be managed (maybe using a nexus proxy) but you need to consider them before rebuilding the build system. At my company we decided to use Ant for all new project and try to port maven 1 and 2 to ant whenever the occasion presents itself. It's just too difficult to keep it working.

My advice, if you and your team know how to deal with ant, try to refactor your ant file and don't jump on some other build tool. It just takes too much time to get it right; time you could spend making money and surviving as a company :)