我现在的团队已经为所有Java开发标准化了NetBeans，我们使用NetBeans生成的ANT文件作为我们的官方构建过程。
但文件总是错误的。
团队的各个成员正在使用不同版本的NetBeans，显然，它们都会生成略有不同的“build-impl.xml”文件。因此，在IDE启动时，NetBeans将重新生成它认为不正确或过时的文件中的任何一个。
然后（因为这些文件被检入源代码控制，作为我们的官方构建脚本），构建文件通常与存储库不同步。如果我从我的机器上检查自动生成的更改，那么我的团队中的其他一些傻瓜将不得不覆盖他自己的构建脚本的本地副本，导致NetBeans抱怨文件已过时且需要再生。
大多数情况下，这是一个烦恼。每次开发人员签入时，自动生成的构建脚本中的虚假差异都会增加大量噪音。或者IDE经常抱怨外部修改的构建脚本。你不能赢。
但我也有一种持续的唠叨感觉，没有人拥有完全正确的构建脚本，我们在整个构建过程中引入了非决定性。
据我所知，这个问题有两种可能的解决方案：
1）标准化特定的NetBeans版本。在我们作为一个团队做出决定之前，不要让人们升级。并且不要让人们在旧版本上徘徊。如果团队中的每个人都使用相同的NB版本，那么这些问题（可能）就会消失。
2）不要将“build-impl.xml”脚本检查到源代码管理中。它由IDE自动生成，因此是“build.xml”和“project.xml”文件的工件。不应将生成的文件（如“.class”文件）检入源代码管理，而应在构建过程中重新生成。弄清楚NetBeans使用什么机制来生成“build-impl.xml”文件，并在我们的构建服务器上执行相同的机制。这是否意味着我们的构建服务器必须依赖NetBeans GUI？我希望不会。
你们觉得怎么样？什么是解决这个问题的正确方法？
答案 0 :(得分：4)
我认为你应该选择第一名，让所有队友使用相同的NetBeans版本。在我的工作中，我们也在NetBeans中开发，但我们都使用相同的版本，并同时进行升级。在过去的两年里，我一直在使用NetBeans，我经历过各种各样的事情随着每个版本（现在更少）而变化，从配置到表单文件，所以我觉得最好尽量减少不同版本的潜在问题。
如果每个人共享相同的环境，它也更容易确定错误的来源。
答案 1 :(得分：0)
如何使用版本化的build-imp.xml.template并忽略关于源代码控制的build-imp.xml。用户可以'轻松'将他们的“个人”构建文件与版本化的文件合并。还能够通过'build-imp.xml.template'将更改传播给他们的同事。
答案 2 :(得分：0)
根据我的意见，以下文件夹不应添加到源代码管理中：
我们不会提交.class文件，实际上是从NetBeans构建过程生成到源控件存储库的任何文件。
所有本地自定义都应在保存在项目根目录中的build.xml文件中完成，如果每个开发人员使用这些自定义项，则不应将其重新提交到存储库。一旦NetBeans项目生成器创建，就不会触及nbproject / build-impl.xml。
问候 图莎尔