NetBeans Build Files Are Never Correct

Question

My current team has standardized on NetBeans for all of our Java development, and we use the NetBeans-generated ANT files as our official build process.

But the files are always wrong.

Various members of the team are using different versions of NetBeans, and evidently, they all generate slightly different "build-impl.xml" files. So, upon IDE startup, NetBeans will regenerate whichever of these files it decides are incorrect or out of date.

But then (since these files are checked into source control, as our official build scripts) the build files are usually out-of-sync with the repository. If I check in the auto-generated changes from my machine, then some other sucker on my team will have to overwrite his own local copy of the build scripts, causing NetBeans to complain that the files are out-of-date and need to be regenerated.

Mostly, this is an annoyance. Either the spurious diffs in auto-generated build scripts add a lot of noise to sift through every time a developer does a checkin. Or the IDE constantly complains about externally-modified build scripts. You can't win.

But I also have a constant nagging feeling that nobody has a fully-correct build script, and we're introducing indeterminism into the whole build process.

As far as I can tell, there are two possible solutions to the problem:

1) Standardize on a particular NetBeans version. Don't allow people to upgrade until we make a decision, as a team, to do so. And don't let people straggle behind on old versions. If everyone on the team uses the same NB version, then these issues will (probably) go away.

2) Don't check the "build-impl.xml" script into source control. It's auto-generated by the IDE and is therefore an artifact of the "build.xml" and "project.xml" files. Generated files (like ".class" files) should not be checked into source control, but should instead be regenerated during the build process. Figure out what mechanism NetBeans uses to generate the "build-impl.xml" file, and execute that same mechanism on our build server. Does this mean that our build server would have to rely on the NetBeans GUI? I hope not.

What do you guys think? What's the right way to solve this problem?

Answer 1

What about using a build-imp.xml.template thats versioned and ignoring the build-imp.xml regarding source control. Users may 'easily' merge their 'personal' build files with the versioned one. Also being able to propagate changes via 'build-imp.xml.template' to their coworkers.

You may have a look at Understand MacroDef Tasks in Netbeans Build Files.

Answer 2

According to my opinion the following folders shall not be added to source control:

1. build (which contains .class files)
2. dist (which contains built JAR files)
3. nbproject/private (while contains local machine specific files)

We shall not commit .class files, in fact anything which gets generated from the NetBeans build process to a source control repository.

All local customizations shall be done in the build.xml file kept in the root directory of the project and those customizations if they are per developer shall not be re-committed to the repository. The nbproject/build-impl.xml shall nt be touched once created by NetBeans project generator.

with regards Tushar

Answer 3

I think you should go for number 1, have all your team mates use the same NetBeans version. At my work we also develop in NetBeans, but we all use the same version, and upgrade at the same time. The past two years I've been using NetBeans, I've experienced that various things changes with every release (less nowadays), from configuration to form files, so I feel its better to minimize potential problems with different versions.

Its also easier to pin-point the source of a bug if everyone shares the same environment.