Buildr, Gradle или ожидают Знатока 3? [закрытый]

maven 3.x уже встроен в IDE (по крайней мере, в netbeans, проверьте эту ссылку для получения дополнительной информации). Сегодня вы можете поиграть с maven 3.x, просто создав проект Maven с помощью netbeans.

Еще одна приятная новость заключается в том, что maven получил большую «корпоративную» поддержку благодаря интеграции EJB / WS в проекты IDE (опять же, по крайней мере, в netbeans).

Так что я бы придерживался maven 2.x для производственных сборок и играл с maven 3.x для разработки.

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

На данный момент maven-2 - хороший выбор для средних 2/3 проектов. Для действительно простых, муравей все еще в порядке. Для действительно сложных становится неизбежным гибрид maven-2 и других инструментов (например, antrun).

Не знаю, почему у вас проблемы с maven-2.

Он отличается от ant и buildr тем, что представляет собой инструмент для описания процесса сборки, а не его написания. Сложные сборки с несколькими динамическими частями и вложенными и / или временными зависимостями сложно построить, потому что их трудно описать.

Я бы не ожидал слишком многого от Maven 3. Люди за родословной инструментами сборки Maven всегда держали предположение, что сборки проекта являются однородными, То есть все проблемы сборки принципиально сводится к той же проблеме. Этот взгляд на мир можно провести довольно последовательно перед лицом противоположных взглядов, но происходит по стоимости. Отсутствие сценариев логики в Maven («Когда вы хотите сценарию, вы знаете, что вы делаете что-то не так»), API громоздки («Ни один обычный пользователь Maven должен захотеть написать плагин») и центральный репозиторий («мы Все имеют те же зависимости ») - это все тестовые одобрения этого всеобъемлющего предположения.

В реальных проблемах сборки народы являются неоднородными, потому что люди создают программное обеспечение для широкого спектра причин. Все они «разрабатывают», как мы все пробивающиеся отверстия от времени для решения уникальных проблем. Независимо от вашего уровня абстракции, вы всегда найдете сходство при сравнении произвольных проблем сборки. Это уверенность этих сходств и осуждение различий, которое является падением для дизайна Maven и причина, по которой он так много рисует. В основном Maven является авторитарным и утопическим в его перспективе.

PS: Maven имеет хорошие особенности, такие как конфигурация конвенции и идея использования репозиториев (реализация этой идеи Maven этой идеи является проблемой).

Maven 2 и 3 отлично работают для меня над множеством проектов. В настоящее время я использую Maven 3 alpha 7, который работает очень хорошо, особенно в сочетании с плагином Eclipse Maven.

Maven легко интегрируется с Ant - в обоих направлениях. В моем текущем проекте мы вызываем Maven из Ant несколько раз, чтобы выполнить сложный интеграционный тест. Точно так же мы используем Ant через плагин Maven AntRun, а также написали собственные плагины Maven.Это, кстати, вопрос минут и сводится к написанию аннотированного Pojo.

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

Ant с Ivy делает то же управление зависимостями, что и Maven (фактически, он использует всю инфраструктуру управления зависимостями Maven, включая те же репозитории URL), но без всей этой путаницы с конфигурацией POM.

Ant с Ivy может быть способом решения проблем зависимостей для людей, которые не хотят использовать Maven. Он решает 90% проблем, которые должен был решить Maven.

Мы используем Maven, но я обнаружил, что как только вы выходите за рамки простого проекта, pom.xml начинает становиться все сложнее и сложнее. Вы начинаете тратить много времени на выяснение того, как, черт возьми, настроить pom на то, что вам нужно, и как обойти различные проблемы.

Больше всего меня зацепило ухо, которое мы собираем. У нас есть несколько вордов в этом файле ear, и Maven обычно помещает библиотеки в ворды. Однако, чтобы уменьшить размер wars и сохранить все банки одинаковыми, мы хотели поместить банки, разделяемые между wars, в каталог lib ear.

К сожалению, Maven не очень хорошо справляется с этим. Нам нужно было вручную настроить это для каждого pom'а wars, а затем добавить все эти зависимости в pom'ы ear.

В другом проекте у нас есть файлы справки на основе HTML. Люди, которые пишут справку, пишут ее в Microsoft Word, а затем используют программу для перевода в HTML. Изменение одного символа может отразиться на сотнях файлов.

Чтобы обойти эту проблему, наша справочная система хранится в репозитории исходных текстов в виде одного заархивированного файла. Когда наша команда разработчиков документации создает новый набор файлов справки, они упаковывают его в zip-архив и заменяют тот, что находится в репозитории.

Таким образом, часть моей сборки заключается в распаковке этого файла и помещении его в войну. Это легко сделать в Ant, в Maven это невозможно, если только вы не используете плагин Antrun, который позволяет вам написать код Ant для решения проблем, которые Maven не может решить без полноценного плагина.

Я понимаю, что делает Maven, но теория опередила реальность. Я обнаружил, что Ivy и Ant могут делать большую часть проверки зависимостей, которую делает Maven, без всех проблем, связанных с написанием и поддержкой poms.

Если вы еще не используете Maven, попробуйте сначала Ant с Ivy. Затем, когда выйдет Maven 3, попробуйте его. Я помню переход от Maven 1 к Maven 2. Они были полностью несовместимы друг с другом, и все, чему вы научились, используя Maven 1, устарело. Было бы глупо изучать и переделывать свои проекты на Maven 2, чтобы потом вдруг обнаружить, что вы переделываете все для Maven 3.