Вопрос

какой смысл использовать ant, maven и buildr?не будет ли использование сборки в eclipse или netbeans работать нормально?мне просто любопытно, какова цель и преимущества расширенных инструментов сборки.

Это было полезно?

Решение

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

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

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

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

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

Взгляните на некоторые серверы непрерывной интеграции, такие как Круиз-контроль или Хадсон.Так же страница функций Maven дает некоторое представление о том, что вы хотите знать.

Другие советы

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

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

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

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

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

Тогда, конечно, есть также прямые преимущества систем сборки. Модульная система сборки уменьшает проблемы с копией вставки и обрабатывает разрешение зависимости и другие проблемы, связанные с сборкой. Этот должен Позвольте разработчикам сосредоточиться на доставке кода. Конечно, каждый новый инструмент вводит свои собственные проблемы, и вовлеченная кривая обучения может показаться, что система сборки - это ненужные накладные расходы (просто Google Я ненавижу Мэвен Чтобы получить представление).

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

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

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

@anonymous,

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

Может быть, я также должен удалить подрывную деятельность и использовать патчи или просто папки ZIP на SHFTP/FTP/SAMBA Share.

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

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

Это чрезвычайно удобно для автоматизации вещей.

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

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

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

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

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

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

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

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

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

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

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top