Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

In my years of programming Java and more recently Scala, I've never used Ant, Maven, Gradle or any of those build tools for Java. Everywhere I've worked there was a build manager who took care of all of that -- I'd compile locally with the IDE for development and unit testing, then check in the source code and notify the build manager who did what was necessary to compile everybody's files for the shared environment.

Now that I'm between contracts I've been working on my own self-funded project and it's getting to the point where it could be good enough to actually make money. I even have a potential investor lined up and plan to show them a beta version in the next few weeks.

But all along I just click the build button on the IDE, and it creates the Jar file and it works just fine. Of course, the conventional wisdom suggests that I "should" be writing my own Ant/Maven/Gradle scripts and using that instead of the IDE, but what are the concrete advantages of that in my situation (working alone)?

I've done some reading about how to use those build tools, and it just looks like I'd be writing hundreds of lines of XML (or Groovy or whatever) to do to what the IDE does in one click (the IDE-generated Ant XML for the project is over 700 lines). It just looks error-prone and time-consuming and unnecessary for my situation. Not to mention the learning curve, which would take away time from all the other work I'm doing to get the product ready to show people.

share|improve this question

migrated from stackoverflow.com Feb 28 '12 at 14:14

This question came from our site for professional and enthusiast programmers.

2  
While you certainly should think about the possability of using Ant/Maven/Gradle scripts to handle the build process. It certainly can wait till a later phase of your development cycle. Don't complicate matters. When you are on track to release something that can be sold, and have an investor, and when it goes beyond just you then consider it. Because it certainly WILL NOT be a "do it once and forget it" task. You will have to keep the script updated to match your build procedures. Worry about the scripts when you have some help. –  Ramhound Feb 28 '12 at 15:30
    
3  
Build tools become beneficial the moment you have more than just "the latest version consisting of all the latest code" to deal with. You are not there yet - the moment you do, tame your build. –  user1249 Feb 29 '12 at 1:19
7  
If what you are doing now works and causes you no problems -- just carry on. "Premature Fixing" probably causes more problems than "Premature Optimization". Besides your IDE is probably using Ant under the covers. –  James Anderson Feb 29 '12 at 1:53
    
Very valid question –  Madhur Ahuja Nov 8 '13 at 10:03

9 Answers 9

up vote 8 down vote accepted

I'd suggest you look into using Maven as opposed to Ant. If your IDE can build your project in one click, then it's likely that Maven can also build your project with virtually no custom configuration.

And to answer the question, simplifying the deployment process is one concrete example. If you're building a distributable locally that means that you have to manually deploy that distributable on your production system, and implies that you probably had to do a fair bit of manual configuration on the production system to get it ready for deployment (installing Tomcat, perhaps, or copying over dependencies and resources required by your application). This can be time-consuming, and may make deploying updates become a tedious, manual process. It also allows the potential for any minor configuration differences between your production platform and your development environment to cause obscure, difficult to track down errors.

So anyhow, what I do to get rid of this manual drudgery is that I configure my project to build with Maven, and I configure my pom.xml file with all the information required to (in the case of a Java web-app) find and download the correct version of Tomcat, install it locally, set up the correct Tomcat configuration files, deploy any project dependencies and the project WAR file itself, and then start Tomcat. I then create a simple shell script (and also a .bat version for Windows) that uses Maven to build and start the server:

mvn clean install cargo:start -Dcargo.maven.wait=true

So instead of packaging up a deployable on my dev environment and then manually pushing it up to production, all I have to do is sync from the version-control system onto the production server, and then the production system itself builds, installs, and runs the deployable (and does it in a way that is identical to how it is done on any development system, minimizing the possibility of platform-specific errors or misconfigurations). And whether in the development or production environment, all I do to build and start the server is:

./startServer.sh #or startServer.bat for Windows

And to deploy an update to the production environment the process is just:

  1. Stop the running server instance, if any.
  2. Run svn update -r<target_release_revision>.
  3. Run ./startServer.sh.

It's simple, easy to remember, and not at all possible to do if I were to rely on using my IDE to build the deployable for me. It also makes reverting to the last-known good deployment a snap, should a rollback ever be necessary.

I can't even count the amount of time this approach has saved me over attempting to manually manage the deployment and configuration process.

And of course, another answer to your question is automatic dependency management, but I believe that's been covered already by other answers.

share|improve this answer
    
I'll continue with the one-click IDE build until the first beta is out. Then I'm planning to use Maven. Ant seems to create more work than it would save for my situation, but Maven appears to be straightforward enough and powerful enough to be worth it. For me it is not just a question of whether there is a benefit to having the build tool; I also weigh the cost of learning it, setting it up and maintaining it. –  Gigatron Mar 10 '12 at 1:11

As long as your code is in source control, using the IDE to make your distributables is fine.

As a one man shop, is your time better spent adding new features to your product, or writing build scripts? Something tells me its not writing build scripts.

share|improve this answer
6  
I disagree 1000 times over. If you structure your build scripts correctly, then you really only have to pay the cost of writing them once, and can then reuse them almost verbatim across any number of projects. There's a lot to be said in favor of having a one-line build command that builds, configures, deploys, and runs the system automatically. And once you have that, it will save a ton of time compared to manual deployment/configuration management, which can then be spent on those new features you mention. –  aroth Feb 28 '12 at 23:41
    
I'd agree that a one-man shop needs to be focused. I disagree on your premise though as build tools would save time on the long term, both to get set up for new projects and maintain existing ones, or even to produce deliverables on demand for customers. –  haylem Feb 29 '12 at 12:05
    
A subtle advantage of Maven is that it works the best with a standard layout of files as opposed to the ad-hoc way frequently seen in Ant projects. When people see the advantage of using Maven defaults they use those, and their projects are easier to understand for future maintainers. –  user1249 Sep 13 '12 at 15:57

Sure, it's harder to see the benefits when you're working alone. Personally, I've worked on plenty of solo projects and not only would I write a build script, I go through the trouble of setting up a CI Server (like Jenkins).

There's overhead of course, why would it be worth it?

  • A reproducible build, not tied to the IDE (or your machine, if you run it externally). If a build server runs it, other machines can run it.
  • The fun begins after building and unit testing (by the way: are you sure you test before every commit? I sometimes forget). Generate documentation, build installers, run your favorite code analysis tools.
  • Your favorite CI server lets you see graphs of code coverage, unit test failures, etc. over time. Does your IDE do that?

For my current project, the script builds, runs static analysis tools, compresses js/css, unit tests, and packages into a web archive. Jenkins runs it after each commit and deploys the project to a test server.

I took the time to set this up (the build script is maybe 300 lines by the way, haven't touched it in months) and can say it's worth it, even for one person. For more than one person, it's necessary. My involvement in the build/deployment process consists of the commands "hg commit" and "hg push."

share|improve this answer
    
Indeed. The the real thing this developer should consider is a good CI solution, and a build script may help get them there. –  Bill Michell Feb 29 '12 at 11:38

Here are my top 4 reasons to use build tools:

  • dependency handling (avoid errors)
  • testing (your change did not break other modules - much easier to test)
  • safe commits
  • easier to deploy local distributable (no one has time in QA env to wait for the builder to build your project and its dependencies)
share|improve this answer
1  
Especially dependency handling. I'm too lazy to download and add external libraries. Much simpler just to add them as a dependency. "Wrong version? Change version in config and rebuild!" –  thoredge Feb 28 '12 at 11:28
    
Yes but dependency handling not really a pre-requisite of all build tools. Maven, Gradle, Ivy support it. Ant, Make, etc... do not. –  haylem Feb 29 '12 at 13:39

Benefits of Build Tools

It's a short summary just showing the tip of the iceberg, and you won't necessarily notice the important of all this unless you need to do with a combination of many projects, large projects and medium to big team. But if you have faith and try, you'll reap the benefits.

They facilitate your development lifecycle and as they allow you to:

  • organize and structure your projects consistently and effortlessly
  • re-use good practices across projects and easily and quickly kick-start them,
  • integrate multiple projets in a single build,
  • automate your continuous integration process,
  • share your project with others
    • without enforcing them to use a specific toolkit or IDE (apart from the build system),
    • and without surprising them as they'll expect a standard build
  • automate and facilitate the maintenance of your product
  • automate your product's release process

If We Apply this to Maven...

For those of you in the Java world and who use Maven, by reading this you naturally associated each point with:

  • Maven's structured project convention
  • Maven Archetypes
  • Materializing a project from SCM and reactor builds
  • Jenkins/Hudson/Bamboo/other support + Maven's support for integration testing practices
  • m2eclipse, native IntelliJ or NetBeans support - or mvnsh for the command line
  • versions-maven-plugin
  • maven-release-plugin, buildnumber-maven-plugin plugin and versions-maven-plugin

And of course, Maven (but other tools as well) gives you dependency management, and that's a huge time and space saver for you (factored to the number of people in your team) and your SCM.

Everything's Relative:

I'm using Maven as an example because I think it is the most comprehensive and "batteries included" build system, but it doesn't mean it's necessarily the "best". It does fit all the tickboxes listed above though, and when looking for a good build system, I compare it to this list and Maven. However, Maven is not always very flexible - it is however very extensible - if you deviate from your standardized process. It boosts your productivy in the general case (once ahead of the learning curve), not if you fight it.

share|improve this answer

In the book Pragmatic Programmer, Andrew Hunt and David Thomas say that 'checkout-build-test-deploy' should be a single command.(Chapter : Pragmatic Projects). You wrote..

I even have a potential investor lined up and plan to show them a beta version in the next few weeks

Then, I am sure your team is going to grow.. It is even more important to have automatic test-deploy abilities done.

The large XML (script) you saw, is typically a one time job. Most of the time, the same scripts can be uses across many projects.

It is not clear how large is the project. If your integrated tests/acceptance tests takes large CPU/memory you may consider using another machine as your test server. You could also deploy host of tools to analyse the source code/byte code.

share|improve this answer

I would argue that, for a lone developer, having good process and structure like scripted builds is vastly more important than when you are on a team. Reason being you don't have teammates to call you out when you cut corners. A CI server running your build script makes for a great uncompromising teammate to keep you honest.

share|improve this answer
    
exactly what I was thinking! I'm currently working on a place where every developer works alone on its own project. I wasn't able sell them the idea of a build system yet, but I'm using it myself cause I think it really helps. –  elias Jun 5 '12 at 23:52

As your code base grows, you will want to add a test suite. My experience is that this should be done sooner rather than later, and that your nightly (or whatever) build should run all the tests every time. Start small, the auto-generated XML is probably fine. When you're scared to change something for fear of breaking something else, that's a good incentive to write up a few test cases.

share|improve this answer
    
I already do unit tests without the need for a separate build tool. The IDE can run the tests or I can run them from the command line. –  Gigatron Feb 28 '12 at 13:02

A non-IDE build makes it easy to rebuild old versions without worrying about reconfiguring your IDE the way it was at the time, lets you perform the build non-interactively so you can maintain a nightly build for people to test, or find out quickly if you broke tests without having to remember to run them and wait for them to complete.

It also lets you perform builds in non-GUI environments, e.g., ssh'ing to a server, and allows you to switch IDEs without worrying about losing the ability to build your software.

Some build tools help you to automate tagging and deploying releases, come with decent defaults for generating code coverage reports, etc.

When you add more people, a build tool will make sure you're not vulnerable to someone else's poor IDE configuration. I regularly do screenshares to fix colleagues' Eclipse installations because they don't use build tools (working on that).

The ultimate reason though is that it is something that doesn't need to be done manually, so don't do it manually. Everything else falls out from that.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.