What's with all the Java Build tools?

Question

what's the point of using ant, maven, and buildr? won't the using build in eclipse or netbeans work fine? i'm just curious what the purpose and benefit of extended build tools are.

Ulm

Answer 1

• Dependency Management: The build tools follow a component model that provides hints on where to look for dependencies. In Eclipse / Netbeans, you have to depend on a JAR and you don't really know if this JAR has been updated or not. With these build tools, they 'know' updates in dependencies (generally because of a good integration with your source control repository), recalculate transitive dependencies and ensure that everything is always built with the latest versions.

• Access Control: Java, apart from class level access control, has no higher abstraction. With these build tools you can specify exactly which projects you want to depend on you and control visibility and access at a higher level of granularity.

• Custom Control: The Eclipse / Netbeans build always builds JAR files. With custom build mechanisms, you could build your own custom (company-internal) archive with extra metadata information, if you so wish.

• Plugins: There are a variety of plugins that come with build tools which can do various things during build. From something basic like generating Javadocs to something more non-trivial like running tests and getting code coverage, static analysis, generation of reports, etc.

• Transport: Some build systems also manage transport of archives - from a development system to a deployment or production system. So, you can configure transport routes, schedules and such.

Take a look at some continuous integration servers like CruiseControl or Hudson. Also, the features page of Maven provides some insight into what you want to know.

Yettayetti

sorry but what's a dependency? – Ulm

Well, if you are doing a personal project, then probably an eclipse build will suffice. However, if you are part of an organization and you are building one component which is part of a larger system, then your component would depend on some other components in the system - which are also in constant development. These are your dependencies. – Yettayetti

i think it should be said that even a personal project require a build tool - and it aint hard to use maven/ant/softsons, or god forbid, even make! Only relying on an IDE to build is a sign of a developer who doesnt care about the way they work. A good crafts man uses good tools, and build tools is one of them. – Berfield

Since NetBeans uses Ant as its underlying build tool (projects.netbeans.org/buildsys/design.html#project-layout) your points also apply to the the NetBeans IDE itself. Your "Custom Control" point is wrong. NetBeans does not use a custom mechanism. Eclipse does not build JAR files by default (viralpatel.net/blogs/2008/12/…). IDEs also uses build tool (with different capabilities of course), hence the comparison does not really fit. IMO the difference between IDEs and build tools is just the user interface. – Benedetta

@Benedetta - I would disagree that the difference between IDEs and build tools is just the UI. 1) I never said that Netbeans uses a custom build mechanism. Please reread what i have written and 2) Just because Netbeans uses Ant internally does not make any of the points i have made invalid. Like i have pointed out, please read about Maven / Hudson / CruiseControl to get a better understanding. – Yettayetti

@Anirudh: OK, I misunderstood your "custom build mechanisms" phrase. Your points are valid but they apply to IDEs as well since IDEs uses build tools too. In case of NetBeans Ant or Maven is used. Hence, no difference in capabilities but in the (G)UI. I know Maven / Hudson / CruiseControl but again if you use Ant or Maven to integrate them it makes no difference for NetBeans. Different points of view are OK and mine is outnumbered after all which is OK for me. – Benedetta

Answer 2

On top of all the other answers. The primary reason I keep my projects buildable without being forced to use NetBeans or Eclipse is that it makes it so much easier to setup automated (and continuous) builds.

It would be rather complicated (in comparison) to set up a server that somehow starts eclipse, updates the source from the repository, build it all, sends a mail with the result and copies the output to somewhere on a disk where the last 50 builds are stored.

Edmond

Wouldn't you just create an executable jar (that you created with an IDE/x build tool) and have a Windows task run the jar file? – Bastian

That's not really how things work if you want the build process to be a part of your CI/CD (which is often a good thing). And, seriously, running Windows? – Edmond

Ok, well you’re working in a much larger org with different needs. Majority of programmers use an IDE. And what’s wrong with Windows Server? – Bastian

So, most devs use their IDE for sure. But when you want to build and test automatically when creating a PR or even automate the build as part of your release. You probably don't want to allocate someone to do the build. That's why it is good to ALSO be able to build your projects from the command line in a script. Windows Server? Well, what is exceptionally good with it? That it makes sure you use all your memory and CPU for trivial things? :-) If you're happy with it, keep using it. (btw, we are 7 but it was just as true in orgs with 100 devs or 2000 devs). – Edmond

Yeah we had a linux box that was running tasks using crontab and it was disastrous. 1. You had to create some sort of mechanism so that if a running task is still running, that it won't run again (task scheduler has a checkbox for this) 2. rsync is vastly slower than robocopy (robocopy allows multithreading copying which can be 10x faster), and 3. linux doesn't have event listening on files so detecting new files and running a task on them required again, more scripting with "flag files" and iterating over the entire folder. – Bastian

I understand that you lack experience from other environments than Windows. Polling? :-D. Anyway, I assume that you are not using anything like CircleCI, Github/Gitlab pipelines. I really don't see any reason why any CI/CD would depend on file system events. They are typically triggered by a webhook call from github (or something similar), monitoring thousands of files is not really the preferred method in NTFS either. I'll stop here. – Edmond

I don't remember mentioning that we use a CI/CD pipeline. But if you peek outside your bubble, there are many companies that offer integration between business partners, and also have workstations in the field that produce files that need importing into a DW -- part of that includes importing the file for time critical applications (altering chemistry in a production line on the fly as soon as a lab machine tests a sample [files saved on a ntfs share go figure]). Polling is not exactly ideal here as I mentioned polling and iterating of 1000x files. I appreciate your gumption. – Bastian

"things are typically triggered by a webhook" -- Not everything in industrial systems/applications are running blogs and shopping cart websites. – Bastian

Eh? You missed my point completely. The fact that github (or whatever you use) emits a webhook so that your CI/CD platform can do a checkout of the code, build it and run tests has nothing to do with shopping carts or blogs. That's how CI/CD pipelines work, no matter if you are writing stock exchanges or software for mobile base stations. You'll figure it out as you get more experienced. – Edmond

My English is fine, thank you :-) My comment was just a response to your strange comment about webhooks and shopping carts. The fact that you have listed other things related to Linux (why does Linux matter here?) is irrelevant. I understand you are not using any CI/CD, but my whole point with the answer you are commenting on was that making sure your projects can be built from a command line makes it easier to get there should you need to. What is your problem with that? And why is it a problem? Most IDE-based project files can be built from the command line at this point (12 years later). – Edmond

yeah it’s strange talking about Linux when you specifically stated it’s better than Windows /s (queue eye roll). And yeah, my point is, it may be better for YOU because you have an automated work flow based on CI/CD but for the majority of developers who don’t need or require it, it is not. – Bastian

Answer 3

If you are a single developer or a very small group, it can seem that a build system is just an overhead. As the number of developers increases though it quickly becomes difficult to track all changes and ensure developers are keeping in sync. A build system reduces the rate of increase of those overheads as your team grows. Consider the issues of building all the code in Eclipse once you have 100+ developers working on the project.

One compelling reason to have a separate build system is to ensure that what has been delivered to your customers is compiled from a specific version of the code checked into your SCM. This eliminates a whole class of "works on my box" issues and in my opinion this benefit is worth the effort on its own in reduced support time. Isolated builds (say on a CI server) also highlight issues in development, e.g. where partial or breaking changes have been committed, so you have a chance to catch issues early.

A build in an IDE builds whatever happens to be on the box, whereas a standalone build system will produce a reproducible build directly from the SCM. Of course this could be done within an IDE, but AFAIK only by invoking something like Ant or Maven to handle all the build steps.

Then of course there are also the direct benefits of build systems. A modular build system reduces copy-paste issues and handles dependency resolution and other build related issues. This should allow developers to focus on delivering code. Of course every new tool introduces its own issues and the learning curve involved can make it seem that a build system is a needless overhead (just Google I hate Maven to get some idea).

Sudd

To borrow from Churchill. It has been said that Maven is the worst form of build tool except all the others that have been tried. – Sudd

Answer 4

The problem with building from the IDE, is that there are tons of settings affecting the build. When you use a build tool all the settings a condensed in a more or less readable form into a small set of scripts or configuration files. This allows in the ideal case anybody to execute a build with hardly any manual setup.

Without the build tool it might become next to impossible to even compile your code in let's say a year, because you'll have to reverse engineer all the settings

Plasticizer

This is a good point. There could be instances where the team doing the testing and building and packing of content will be different from the development team and will not necessarily have an IDE installed (and consequently, no IDE settings). It is then important to have the build settings outside of your IDE. – Yettayetti

Answer 5

Different features. For example Maven can scan your dependencies and go download them, and their dependencies so you don't have to. For even a medium sized project there may be a very large number of dependencies. I don't think Eclipse can do that.

Urion

Eclipse can do that... with Maven plugin. – Cobol

@gigory: so in the end, its still maven! – Berfield

Answer 6

@anonymous,

• Why do you I assume that me, a member of your team, is using an IDE all the time? I might want to build the code on a headless build server, is that ok?
• Would you also deny me the right of using a continuous integration engine?
• May I fetch dependencies from a central repository please? How can I do that?
• Would you tie me to a specific IDE? I can't run Eclipse easily on my very old laptop, but I'll buy a new one.

Maybe I should also uninstall subversion and use patches or just zip folders on a sftp/ftp/Samba share.

Demavend

forget about it, to put it simply, if the only person using your code or touching it, is you, then do as you please. – Demavend

These are good points, but I'd be more inclined to upvote this if you didn't phrase it as these condescending questions – Woofer

Plenty of companies do assume you are using an IDE, and in many they assume you are in fact using the same IDE as everyone else. I don't think you meant your post to sound sarcastic and mean, but it does, which is not in the spirit of SO, IMHO. The points you raise are are valid, but someone who needs to ask this question in the first place might need a little more explanation and a little less snark. – Grendel

The same could be said about the tone of the question. – Cotoneaster

My answer was meant to be sarcastic but not mean. The sarcasm was meant to make him realize the importance of build tools. But I guess I failed miserably. @Peter, What should I explain when you say "little more explanation"? @anonymous asked @Yettayetti what a dependency was. Should I write a manual when he could google "integration engine etc.?" Yes, companies assume that you're using an IDE, usually the same IDE, no problem. If you can't build code without an IDE in your company, it means to me that the company doesn't know much about software development in general, no offense. – Demavend

Answer 7

The build tools allow you to do a build automatically, without human invention, which is essential if you have a code base being able to build many applications (like we do).

We want to be certain that each and everyone of our applications can build correctly after any code base changes. The best way to check that is to let a computer do it automatically using a Continouos integration tool. We just check in code, and the CI server picks up there is a change and rebuilds all modules influenced by that change. If anything breaks the responsible person is mailed directly.

It is extremely handy being able to automate things.

Belsky

Answer 8

To expand on Jens Schauder's answer, a lot of those build options end up in some sort of .project file. One of the evils of Eclipse is that they store absolute path names in all of it's project files, so you can't copy a project file from one machine to another, which might have its workspace in a different directory.

The strongest reason for me, is automated builds.

Piperonal

Tosh. Eclipse only stores absolute paths if set it up to do so. If you use classpath containers, variables, or workspace-relative references there are no absolute paths. Don't blame the tool for your bad practices. – Sudd

Answer 9

IDEs just work on a higher abstraction layer.

NetBeans nativly uses Ant as its underlying build tool and recently can directly open maven projects in NetBeans. Hence, your typical NetBeans project can be compiled with ant and your maven project already is a NetBeans project.

As with every GUI vs CLI discussion, IDEs seem easier for beginners but once you get the idea it becomes cumbersome to do complex things.

Changing the configuration with an IDE means clicking somewhere which is easy for basic things but for complex stuff you need to find the right place to click. Furthermore IDEs seem to hide the importent information. Clicking a button to add a library is easy but you may still not know where the library is, etc.

In contrast, using a CLI isn't easy to start with but becomes quickly easy. It allows to do complex things more easily.

Using Ant or Maven means that every one can choose his/her own IDE to work one the code. Telling someone to install IDE X to compile it is much more overhead than telling "run <build command> in your shell". And of course your can't explain the former to an external tool.

To sum up, the IDE uses a build tool itself. In case of NetBeans Ant (or Maven) is used so you can get all the advantages and disadvantages of those. Eclipse uses its own thing (as far as I know) but also can integrate ant scripts.

As for the build tools themselves Maven is significantly different from Ant. It can download specified dependencies up to the point of downloading a web server to run your project.

Benedetta

Answer 10

In all projects, developers will often manually invoke the Build process.but it is not Suitable for large Projects, Where it is very difficult to keep track of what needs to be built, in what sequence and what dependencies there are in the building process.Hence we Use Build Tools for Our Projects.
Build Tools Done varieties of the task in the Application which will do by the Developer in their daily life.
They are
1.Downloading dependencies.
2.Compiling source code into binary code.
3.Packaging that binary code.
4.Running tests.
5.Deployment to production systems.

Lohner