Файлы сборки NetBeans никогда не бывают правильными

Question

Моя текущая команда стандартизировала NetBeans для всех наших разработок на Java, и мы используем сгенерированные 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?Я надеюсь, что нет.

Что вы, ребята, думаете?Как правильно решить эту проблему?

Answer 1

Я думаю, вам следует выбрать номер 1, чтобы все ваши товарищи по команде использовали одну и ту же версию NetBeans. На моей работе мы также разрабатываем в NetBeans, но все мы используем одну и ту же версию и обновляем одновременно. В течение последних двух лет, когда я использовал NetBeans, я сталкивался с тем, что с каждым выпуском меняются разные вещи (в настоящее время меньше), от конфигурации до файлов форм, поэтому я считаю, что лучше минимизировать потенциальные проблемы с разными версиями.

Также проще определить источник ошибки, если все используют одну и ту же среду.

Answer 2

По моему мнению, следующие папки не должны добавляться в систему контроля версий:

1. build (который содержит файлы .class)
2. dist (который содержит встроенные файлы JAR)
3. nbproject / private (пока содержит файлы, специфичные для локальной машины)

Мы не будем фиксировать файлы .class, фактически все, что генерируется из процесса сборки NetBeans, в репозиторий управления исходным кодом.

Все локальные настройки должны выполняться в файле build.xml, хранящемся в корневом каталоге проекта, и эти настройки, если они принадлежат одному разработчику, не должны повторно передаваться в хранилище. Файл nbproject / build-impl.xml нельзя трогать после создания генератором проекта NetBeans.

с уважением Tushar

Answer 3

Как насчет использования build-imp.xml.template, который версирован, и игнорирования build-imp.xml в отношении контроля версий. Пользователи могут 'легко' объединять свои «личные» файлы сборки с версионными. Также возможность распространять изменения через «build-imp.xml.template» на своих коллег.

Вы можете взглянуть на Понимание задач MacroDef в файлах сборки Netbeans .