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

Ответ 1

• Управление зависимостями. Инструменты сборки следуют за моделью компонентов, которая дает подсказки о том, где искать зависимости. В Eclipse/Netbeans вы должны зависеть от JAR, и вы действительно не знаете, обновлен ли этот JAR или нет. С помощью этих инструментов сборки они "знают" обновления в зависимостях (как правило, из-за хорошей интеграции с репозиторием исходного источника), пересчитывают транзитивные зависимости и обеспечивают, чтобы все всегда было построено с использованием последних версий.

• Контроль доступа. Java, помимо контроля доступа к уровню, не имеет более высокой абстракции. С помощью этих инструментов сборки вы можете точно указать, какие проекты вы хотите зависеть от вас, и контролировать видимость и доступ на более высоком уровне детализации.

• Пользовательский контроль: сборка Eclipse/Netbeans всегда создает файлы JAR. С помощью пользовательских механизмов сборки вы можете создать собственный собственный (корпоративный) архив с дополнительной информацией метаданных, если хотите.

• Плагины. Существует множество плагинов, которые поставляются с инструментами построения, которые могут выполнять различные функции во время сборки. От чего-то такого, как генератор Javadocs, к чему-то более нетривиальному, например, к запуску тестов и получению покрытия кода, статическому анализу, генерации отчетов и т.д.

• Транспорт. Некоторые системы сборки также управляют транспортировкой архивов - от системы разработки до системы развертывания или производства. Таким образом, вы можете настроить маршруты транспорта, расписания и т.д.

Взгляните на некоторые серверы непрерывной интеграции, такие как CruiseControl или Hudson. Кроме того, страница страницы Maven дает некоторое представление о том, что вы хотите знать.

Ответ 2

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

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

Ответ 3

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

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

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

Тогда, конечно, есть также прямые преимущества систем сборки. Модульная система сборки уменьшает проблемы с копированием и вставкой и обрабатывает разрешение зависимостей и другие проблемы, связанные с построением. Это должно позволить разработчикам сосредоточиться на доставке кода. Разумеется, каждый новый инструмент вводит свои собственные проблемы, и задействованная кривая обучения может создать впечатление, что система сборки является ненужной накладной (просто Google Я ненавижу Maven чтобы получить некоторую идею).

Ответ 4

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

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

Ответ 5

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

Ответ 6

@anonymous,

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

Возможно, мне также следует удалить подрывную работу и использовать патчи или просто папки с zip файлом на ресурсе sftp/ftp/Samba.

Ответ 7

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

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

Очень удобно иметь возможность автоматизировать вещи.

Ответ 8

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

Самая сильная причина для меня - автоматические сборки.

Ответ 9

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

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

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

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

В отличие от этого, с помощью CLI начать нелегко, но быстро становится легко. Это позволяет делать сложные вещи более легко.

Использование Ant или Maven означает, что каждый может выбрать свою собственную среду IDE для работы с кодом. Говорить кому-то, чтобы установить IDE X для компиляции, это намного больше накладных расходов, чем говорить "run < build command > в вашей оболочке". И, конечно, вы не можете объяснить первое внешнему инструменту.

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

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

Ответ 10

Во всех проектах разработчики часто будут вручную ссылаться на процесс сборки. Но это не подходит для крупных проектов, где очень сложно отслеживать, что нужно построить, в какой последовательности и каких зависимостях в строительный процесс. Мы используем инструменты сборки для наших проектов.
Build Tools Выполняет разновидности задачи в приложении, которое будет выполнять Разработчик в повседневной жизни.
Они
1. Загрузки зависимостей.
2. Компиляция исходного кода в двоичный код.
3.Упаковка этого двоичного кода.
Тесты 4.Running.
5. Внедрение в производственные системы.