Что со всеми инструментами Java Build?

Вдобавок ко всем остальным ответам. Основная причина, по которой я сохраняю возможность сборки моих проектов без необходимости использования NetBeans или Eclipse, заключается в том, что это значительно упрощает настройку автоматизированных (и непрерывных) сборок.

Было бы довольно сложно (по сравнению) настроить сервер которая каким-то образом запускает eclipse, обновляет исходный код из репозитория, строит все это, отправляет письмо с результатом и копирует вывод куда-нибудь на диск, где хранятся последние 50 сборок.

Если вы один разработчик или очень небольшая группа, может показаться, что система сборки - это просто накладные расходы. По мере увеличения количества разработчиков становится все труднее отслеживать все изменения и обеспечивать синхронизацию разработчиков. Система сборки снижает скорость увеличения этих накладных расходов по мере роста вашей команды. Рассмотрите проблемы построения всего кода в Eclipse, когда над проектом будут работать более 100 разработчиков.

Одной из веских причин для создания отдельной системы сборки является обеспечение того, чтобы то, что было доставлено вашим клиентам, было скомпилировано из ] конкретную версию кода, зарегистрированную в вашем SCM . Это устраняет целый класс проблем «работает на моем ящике», и, на мой взгляд, это преимущество стоит затраченных усилий, так как время поддержки сокращается. Изолированные сборки (например, на CI-сервере ) также выделяют проблемы в разработке, например, когда были зафиксированы частичные или критические изменения, так что у вас есть шанс выявить проблемы на раннем этапе.

Сборка в среде IDE строит независимо от того, что находится на коробке, тогда как автономная система сборки будет производить воспроизводимую сборку непосредственно из SCM. Конечно, это можно сделать в среде IDE, но AFAIK только путем вызова чего-то вроде Ant или Maven для обработки всех шагов сборки.

Тогда, конечно, есть также прямые преимущества систем сборки. Модульная система сборки уменьшает проблемы копирования-вставки и обрабатывает разрешение зависимостей и другие проблемы, связанные со сборкой. Это должно позволить разработчикам сосредоточиться на доставке кода.

Проблема со сборкой из IDE состоит в том, что на сборку влияет множество настроек. Когда вы используете инструмент сборки, все настройки конденсируются в более или менее читаемой форме в небольшой набор скриптов или файлов конфигурации. В идеальном случае это позволяет любому выполнить сборку без какой-либо ручной настройки.

Без инструмента сборки может стать практически невозможно даже скомпилировать ваш код, скажем, за год, потому что вам придется перепроектировать все настройки

Инструменты сборки позволяют выполнять сборку автоматически, без вмешательства человека, что очень важно если у вас есть кодовая база, позволяющая создавать множество приложений (как это делаем мы).

Мы хотим быть уверены, что каждое из наших приложений сможет правильно построить после любых изменений кодовой базы. Лучший способ проверить это - позволить компьютеру делать это автоматически с помощью инструмента интеграции Continouos. Мы просто проверяем код, и CI-сервер определяет, есть ли изменение, и перестраивает все модули, на которые повлияло это изменение. Если что-то ломается, ответственное лицо отправляется напрямую по почте.

Чтобы расширить ответ Йенса Шаудера, многие из этих параметров сборки попадают в какой-то файл .project. Одним из недостатков Eclipse является то, что они хранят абсолютные имена путей во всех своих файлах проекта, поэтому вы не можете скопировать файл проекта с одного компьютера на другой, рабочее пространство которого может находиться в другом каталоге.

Самый сильный Причина для меня - это автоматизированные сборки.

IDE просто работают на более высоком уровне абстракции.

NetBeans изначально использует Ant в качестве основного инструмента сборки и в последнее время может напрямую открывать проекты maven в NetBeans. Следовательно, ваш типичный проект NetBeans может быть скомпилирован с помощью ant, а ваш проект maven уже является проектом NetBeans.

Как и при любом обсуждении GUI и CLI, IDE кажутся проще для новичков, но как только вы поймете, что делать сложные вещи становится громоздко .

Изменение конфигурации с помощью IDE означает щелчок в любом месте, что легко для базовых вещей, но для сложных вещей вам нужно найти правильное место для щелчка. Кроме того, кажется, что IDE скрывают важную информацию. Нажать кнопку, чтобы добавить библиотеку, легко, но вы все еще можете не знать, где находится библиотека и т. Д.

Напротив, использовать CLI нелегко начать, но быстро становится легко. Это упрощает выполнение сложных задач.

Использование Ant или Maven означает, что каждый может выбрать свою собственную IDE для работы с кодом. Сказать кому-то установить IDE X для компиляции - гораздо больше накладных расходов, чем сказать «запустить в вашей оболочке». И, конечно, вы не можете объяснить первое внешнему инструменту.

Подводя итог, IDE использует сам инструмент сборки. В случае использования NetBeans Ant (или Maven), вы можете получить все их преимущества и недостатки. Eclipse использует свою собственную вещь (насколько я знаю), но также может интегрировать скрипты ant.

Что касается самих инструментов сборки, Maven значительно отличается от Ant. Он может загружать указанные зависимости вплоть до загрузки веб-сервера для запуска вашего проекта.

Использование Ant или Maven означает, что каждый может выбрать свою собственную IDE для работы с кодом. Сказать кому-то установить IDE X для компиляции - гораздо больше накладных расходов, чем сказать «запустить в вашей оболочке». И, конечно, вы не можете объяснить первое внешнему инструменту.

Подводя итог, IDE использует сам инструмент сборки. В случае использования NetBeans Ant (или Maven), вы можете получить все их преимущества и недостатки. Eclipse использует свою собственную вещь (насколько я знаю), но также может интегрировать скрипты ant.

Что касается самих инструментов сборки, Maven значительно отличается от Ant. Он может загружать указанные зависимости вплоть до загрузки веб-сервера для запуска вашего проекта.

Использование Ant или Maven означает, что каждый может выбрать свою собственную IDE для работы с кодом. Сказать кому-то установить IDE X для компиляции - гораздо больше накладных расходов, чем сказать «запустить в вашей оболочке». И, конечно, вы не можете объяснить первое внешнему инструменту.

Подводя итог, IDE использует сам инструмент сборки. В случае использования NetBeans Ant (или Maven), вы можете получить все их преимущества и недостатки. Eclipse использует свою собственную вещь (насколько я знаю), но также может интегрировать скрипты ant.

Что касается самих инструментов сборки, Maven значительно отличается от Ant. Он может загружать указанные зависимости вплоть до загрузки веб-сервера для запуска вашего проекта.

Различные функции. Например, Maven может сканировать ваши зависимости и скачивать их вместе с зависимостями, поэтому вам не нужно этого делать. Даже для проекта среднего размера может быть очень большое количество зависимостей. Я не думаю, что Eclipse может это сделать.

@anonymous,

• Почему вы предполагаете, что я, член вашей команды, использует IDE все время? Я мог бы захотеть построить код на сервере сборки без головы, это хорошо?
• Не могли бы вы также отказать мне в праве с использованием непрерывной интеграции двигатель?
• Можно мне получить зависимости из центрального репозитория? Как я могу это сделать?
• Не могли бы вы привязать меня к конкретной среде IDE? Я не могу легко запустить Eclipse на моем очень старом ноутбуке, но я куплю новый.

Может быть, мне также следует удалить Subversion и использовать исправления или просто заархивировать папки на общем ресурсе sftp / ftp / Samba.