Зачем нам Maven или Ant, если у нас уже есть Eclipse?

Ответ 1

• Потому что ваш коллега может предпочесть NetBeans или IDEA
• Поскольку настройки могут отличаться от одной установки eclipse к другому
• Поскольку вы можете автоматически получать свои зависимости
• Поскольку вы хотите автоматизировать полную сборку: build, jar, применять статический анализ кода, запускать модульные тесты, создавать документацию, копировать в какой-либо каталог, настраивать некоторые свойства в зависимости от среды и т.д.
• Потому что, как только он автоматизирован, вы можете использовать систему непрерывной интеграции, которая строит приложение при каждом изменении или каждый час, чтобы убедиться, что все еще построено и тесты все еще проходят...
• Поскольку Maven использует соглашение по конфигурации.
• Потому что ваша среда IDE может не поддерживать некоторые генерации/преобразования воображаемого кода, которые вам нужны.
• Поскольку сборка script документирует процесс сборки.

Eclipse - это среда разработки. Но это не инструмент сборки.

Я лично ненавижу Maven, но YMMV. Существует много альтернатив: gradle, buildr и т.д.

Ответ 2

Maven поражает меня как случай чего-то, написанного кучей старых детей c-shell script, которые думают, что autoconf - это автоматизация передового кода и не понимает, что объектный код требует объектная среда должна быть в любом случае эффективна либо для разработки, либо для развертывания. Ant был достаточно плохим, но Maven сочетает в себе все худшие особенности Ant и Ivy. Он не создает объектную среду, и он не очень хорошо работает с инструментами.

Просто объектная среда должна иметь все объекты класса, то есть объекты, которые определяют типы объектов, доступных для системы, всегда доступны и доступны. Оттуда я могу делать все, что захочу, создавать несколько объектов класса, настраивать различные последовательности и правила создания экземпляров и т.д. Поскольку среда должна быть полностью живой, мне не нужен инструмент построения вообще. С точки зрения развертывания моего приложения, для окружающей среды нетрудно просто выбросить все объекты класса, которые никогда не ссылаются на код в пространствах имен, составляющих мое приложение. Сборщик мусора в JVM делает почти то же самое на лету сегодня. В этот момент у меня есть среда развертывания, состоящая из моих объектов и всех объектов (прежде всего объектов класса), с которыми связаны мои объекты, то есть мое приложение и все зависимости. Так работают виртуальные машины. (что наши виртуальные машины так плохо написаны, нам нужно запустить VM Spring на виртуальной машине Java на виртуальной машине Linux на VMWare VM на другой Linux VM - еще один пример идиотизма разработки программного обеспечения). Когда зависимости обновляются, это достаточно просто, чтобы среда предложила разработчику объединить свой старый код в новые библиотеки, объединить код, используя новые библиотеки, до более старой версии или сохранить обе версии. Подсказка побуждает разработчика внести небольшие изменения, которые иногда необходимы, чтобы избежать наличия 20 версий каждой библиотеки, в то время как такие инструменты, как Maven, скрывают тот факт, что у вас есть двадцать версий и приводят к массовому раздутию времени выполнения, распространенному в Java-приложениях.

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

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

Не серьезная причина использовать Maven.

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

Опять же, не серьезная причина использовать Maven.

Командная окружение? Покажите мне команду, которая еще не использует репозиторий типа GIT или SVN. Почему мы должны дублировать как функциональность, так и головную болью обслуживания, настраивая также репозитории Nexus?

Это действительно хорошая причина НЕ использовать Maven.

Запуск сборки сервера? Отличная идея, не следует ли начинать с кода, который фактически проверяется на исходном репо, а не на случайную сборку, которая, как оказывается, попадает в Nexus? Это вызывает точку против Git, особенно GIT с Maven. Поскольку в GIT я не работаю в ветки, проверяю локально, а затем фиксирую (частично потому, что мой локальный тест не доказывает, что сборка сервера работает из-за различий в конфигурации Maven в Jenkins и Eclipse), я должен выполнить изменения в другой ветке, чтобы убедиться, что сборка сервера Maven завершилась с ошибкой, а затем совершить дальнейшее изменение, чтобы исправить проблему, что привело к нечитаемой исходной истории в репо. Проверенный код должен, по крайней мере, строить и проходить модульные тесты, которые должны были быть гарантированы GIT и Maven.

Экспорт безглавой сборки из Eclipse является тривиальным, если вы действительно смотрите на него - все, что вам нужно, это Ant или Gradle, сборка разработчика уже поддерживается Eclipse и несколько баннеров Eclipse (Eclipse будет экспортировать все необходимые файлы для безголовой сборки в каталог или zip файл, или ftp их на сервер сборки). Инструменты построения сервера, такие как Hudson/Jenkins, могут вытаскивать обновленный код из большинства исходных репозиториев и вызывать любую сборку script, там нет зависимости от Maven. С Maven вы заставляете разработчиков использовать инструмент, который не подходит никому, кроме инженеров-строителей (максимальные значения, которые требуется для сборки, даже с использованием M2E, достаточны для этого случая), или вы живете с возможностью создания сервера не работает так же, как сборка рабочей станции, что по-прежнему справедливо, если вы преодолеете все трудности интеграции этих двух приложений с использованием множества плагинов M2E. В любом случае вы получаете более медленную и более хрупкую рабочую станцию ​​для столь же медленной и более хрупкой сборки сервера. На каждом проекте, основанном на Maven, над которым я работал, я видел временные ошибки Hudson/Jenkins, которые не отображаются в Eclipse, если у вас нет абсолютно всех возможных плагинов M2E, установленных и правильно настроенных, и большинство разработчиков никогда этого не делают.

Похоже на другую великую причину, чтобы избежать Maven.

Это не затрагивает некоторые более фундаментальные проблемы с Maven, такие как пространства имен, которые разбивают пространства имен Java и пространства имен XML, блок сборки (POM) не имеет никакого отношения ни к чему в реальной среде развертывания (подумайте об этом, когда вы разделяете через POM, что вы на самом деле выполняете в готовом продукте? Ничего. Все, что он выполняет, - это ложное ощущение, что вы разделяли проблемы и функциональность в разных блоках сборки, которые все работают как одна монолитная часть кода); хлопот вручную поддерживать сложные файлы конфигурации, что только ухудшается, если вам нужно использовать OSGi или другой контейнер и поддерживать другие файлы конфигурации, которые влияют и зависят от конфигурации Maven с очень небольшим очевидным смыслом; проблемы, вызванные попыткой запуска модульных тестов без полной среды для выполнения кода; множество версий не только зависимостей, но и отдельных плагинов Maven (я на самом деле видел JAR-ад в самой Maven, где несколько плагинов Maven использовали конфликтующие зависимости - одна из проблем, которые должен был решить Maven.

Да, вы можете создать объектный код с Maven. Вы также можете написать чистый объектный код на C или даже на ассемблере, но я не знаю, почему вы хотите.

Лучшей причиной, чтобы избежать Maven, является феноменальный объем работы, требуемый для де-mavenize ряда проектов, когда вам надоедают все проблемы, отмеченные выше (и многие другие, не упомянутые).

Умение, унаследованное от разработки C, заключается в том, что цикл разработки состоит из написания кода, компиляции, сборки, сборки, развертывания, тестирования, повторного выполнения, безнадежно устарел в объектной среде. В какой-то момент нам нужно рассказать всем людям с этим мышлением, что им нужно переучиться, как развиваться, период. Это позволит устранить любую потребность в Maven, Git и целый ряд других инструментов, которые ничего не делают, кроме времени траты.

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

В настоящее время я имею дело с проблемой, вызванной созданием сборок для приложения OSGi с использованием плагина maven-assembly. Приложение отлично работает в среде Eclipse, которая hot развертывает все изменения кода в запущенный контейнер OSGi в среде. Однако конфигурация не сохранилась без изменений через процесс сборки maven, несмотря на наличие очень хорошего инженера по настройке/сборке, единственной задачей которого является выполнение этого процесса. Если бы мы избавились от Maven (сейчас очень сложно из-за количества кода, но возможно) и использовали плагин BNDTOOLS Eclipse, мы могли бы просто экспортировать сборку Eclipse в виде сборки без заголовка Ant или Gradle (заметьте, разработчики OSGi которые пишут BND и BNDTOOLS, не поддерживают Maven, и не зря, плагин Maven написан разработчиками Felix, которые сами используют Netbeans и Maven, и никакой живой среды, кроме как в конце цикла развертывания), где оба инструмента настройте ту же среду, что и Eclipse, без объектов GUI, которые в любом случае предназначены только для разработчиков. Результатом будет идентичная конфигурация и сборка для развертывания. Это позволило бы сэкономить 2-3 часа в день на одного разработчика, потраченного в настоящее время на просмотр медленных Maven или M2E, и освободить инженера конфигурации/сборки, чтобы больше тестировать приложение на узлах развертывания.

Преодоление менталитета записи/компиляции/сборки/сборки/развертывания/теста является единственным серьезным препятствием. Притворяясь, что вы кодируете терминал VT100 1979 года вместо современной машины, вы не являетесь "настоящим" разработчиком, он просто демонстрирует, что ваши методы устарели 35 лет.

Из разработчиков в команде никто из других не правильно понимает среду живых объектов, такую ​​как Eclipse, чтобы заставить ее работать как живая среда с M2E и OSGi, и они являются главными разработчиками, они просто не были открыты к нему из-за преобладания устаревших инструментов разработки командной строки. Они только поняли, что это можно сделать, когда мы были парным программированием для решения проблемы конфигурации, и я делился своим экраном, в результате чего один из других членов команды воскликнул: "Вот как вы так быстро пишете код", когда он увидел мой изменение кода мгновенно проверяет себя в фоновом контейнере OSGi. Я могу использовать оболочку bash, когда это необходимо, например, когда я просматриваю журналы на удаленном сервере, на самом деле я делаю это достаточно эффективно, поэтому я могу как можно быстрее выйти из этой среды и вернуться к XXI век.

Ответ 3

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

Фактически Eclipse сам использует Ant для создания плагинов.

Если вы изучили одного из двух, узнайте Maven, это тот, который каждый использует в наши дни (заменяя Ant).

Ответ 4

Существует много преимуществ использования Ant или Maven.

Maven более или менее представляет собой концепцию обновления Ant. Вместо того, чтобы дать вам ответ на пулевую точку, я решил взять другой подход, чтобы ответить на этот вопрос. Я задам вам простой вопрос. Я предполагаю, что вы будете разработчиком; или иметь какой-то фон программирования OO.

Итак, если ваш менеджер попросил вас скопировать две сотни каталогов, но игнорировать jar, war and ear файлы в этих каталогах и после их копирования. Затем вы развертываете эти 200 каталогов в другой пункт назначения, но развертываете только файлы .class; копировать остальные файлы в другое место назначения и т.д.

Чтобы сделать это в java; это будет много логики, много кода и не будет расширяемым или адаптируемым к изменениям. Поэтому, имея в виду Ant, или Maven выполнит и подготовит все это "на лету" с меньшими накладными расходами для использования вашего приложения. Размер кода в Ant или Maven будет 1/4 сравним с Java.

Нажмите на ссылки для получения дополнительных технических преимуществ:

Maven

Ant Я не смог найти аутентичный ответ с выгодой, но я уверен, что это убедит вас;)

Ответ 5

Maven обычно используется для создания плагинов или баннеров для конкретного приложения.

Предположим, что вы разработали приложение, но не хотите, чтобы вы добавляли банки, необходимые для этого приложения, вручную. В этой ситуации Maven или Ant очень полезны. После того, как вы написали свой код, который только что получил, чтобы запустить As → Maven Build (нажмите Maven Build), он сгенерирует все необходимые плагины или банки и включит их в путь сборки вашей библиотеки приложений. Может возникнуть сомнение в том, как приложение получит эти банки. Для каждого приложения есть xml файл с именем POM.xml, где ссылки на все банки хранятся там для целей загрузки.