Почему так мало людей используют Maven? Существуют ли альтернативные инструменты?

Ответ 1

В java и в рубиновом сообществе есть много альтернатив. Для обзора посмотрите это изображение

Ответ 2

IMO Maven - переработанная машина Рубе Голдберга или, по словам Грэма Рошера (Grails проект), EJB2 инструментов сборки.

Я думаю, что цели проекта Maven очень достойны. Контракт над конфигурацией? Большой! Автоматическое разрешение зависимостей? Супер! Но, к сожалению, практика сильно отличается от теории. По моему опыту, введение Maven в проекты, которые ранее были построены с помощью Ant, неизменно создавало больше проблем, чем было решено. В одном случае Maven начал заниматься таким большим количеством времени, что мы в конце концов снова вернулись к Ant.

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

Проблема с Maven заключается в том, что она на самом деле довольно негибкая, если вам нужно сделать что-то, что противоречит соглашениям Maven. Хотя вы можете переопределить эти соглашения в некоторых тривиальных случаях (например, смените имя исходной папки с src на source), некоторые из этих условных обозначений, как представляется, установлены в виде камня, например. один артефакт для каждого проекта. Возьмем пример веб-проекта Maven, артефакт которого является .war файлом. Теперь представьте, что мы хотели бы включить текущий номер версии SVN в .war имя файла. Это не похоже на то, что это должно быть особенно сложно достичь, но если вы не можете найти плагин, который уже делает это, вам, вероятно, придется написать свой собственный плагин для его достижения, что не является тривиальной задачей, поскольку это требует вы должны понимать модель жизненных циклов и целей Maven.

Чтобы ответить на вторую часть вашего вопроса об альтернативах: я не использовал ее лично, но слышал очень хорошие вещи о Gradle. Ряд высококлассных проектов JVM, таких как Spring и Hibernate, которые ранее были построены с Maven, недавно переключились на Gradle.

Ответ 3

Мне нравится Maven и использую его почти исключительно в моей компании. Но я оправдываю свои причины для этого:

• Я запускаю команду разработчиков, и мы требуется структура. Мне нужна большая часть моего разработчикам следовать определенный набор конвенций вплоть до проекта макеты. Это делается для упрощения для передачи обслуживания при истощении.
• Архетипы Maven являются основными благословение в этом отношении. Старшие будет просто создавать конкретные архетипы для определенного проекта шаблоны, которые все разработчики просто основывать свои проекты на. Там есть действительно простой общий для тех случаев, когда нам не удавалось обслуживать. Проверка ant макет из SVN менее интуитивно понятен в в этом отношении разработчик по-прежнему необходимо удалить оригинал .svn метаданные после проверки из.
• Maven помогает нам оставаться в среде IDE-агностик. Я не хочу основывать ни один из моих наняв политику в отношении того, разработчик предпочитает использовать. Не менее 2 основные IDE (Eclipse и NetBeans) имеют довольно хорошую интеграцию Maven уже такой, что a pom.xml файл уже имеет определение проекта IDE. Я могу сказать любой новый разработчик, который он может использовать независимо от того, какой IDE он предпочитает до тех пор, пока сама система сборки основана на Maven.
• Я обнаружил, что разработка бутстрап-процесс для сбора вещи на полпути резко сократились когда я переключился на Maven. новый разработчиков, даже незнакомых с проектом под рукой, по крайней мере, скомпилировать, развернуть в течение получаса брифинга их проекта. Вспомогательный персонал (которые, как правило, не такие технически адепт) смогли сосредоточиться на устранении неполадок и не беспокоиться о строительстве проекта, что является ненужным раздражением.

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

Ответ 4

Много ошибок Maven, с которыми я столкнулся, перечислены и указаны в этой записи . Мой опыт заключается в том, что разработчики Java используют полный контроль над своими проектами. Многие из причин, по которым они против Maven, в основном "это не ant", или я не могу делать X, как я могу, в ant ".

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

Таким образом, учитывая негативы, понятно, что люди были бы не склонны вкладывать время и силы в инструмент построения, когда вы можете пойти с тем, что знаете (ant/make/whatever), и продолжить "выполнение задания" ", ведь ваши клиенты не заботятся о том, насколько сексуально ваш процесс сборки.

Ответ 5

После перенастройки слишком много проектов на maven (от чистого java до чистого javascript и xslt проектов), я думаю, что плюсы: использование maven - 50:50. Наиболее важными минусами являются:

• невероятно медленный
• значительно замедляет цикл разработки-развертывания-тестирования
• имеет смешную структуру проекта. Если вы не разрабатываете чистый проект java, структура не имеет смысла.
• Процесс сборки указан декларативно. Что более ясно: <copy from="" to=""/> или регистрация плагина mvn и определение тонны свойств?
• mvn авторы склонны к конструктивной критике

Ответ 6

Я думаю, что Maven страдает от относительно высокого барьера для входа по сравнению с такими инструментами, как Ant. Трудности с более ранними версиями и сложностью 2.0 удержали меня. Это не 100% необходимо, особенно если у вас хорошая IDE.

Ответ 7

Для альтернативного инструмента я предлагаю Gradle. Он основывается на Ant и Maven и поддерживает все стандартные цели (компиляция, модульные тесты и т.д.). Ключевым преимуществом является то, что конфигурация находится в Groovy, что делает текучие, сжатые файлы. (Тем не менее, в какой-то степени нужно будет изучить Groovy).

Ключевым моментом является то, что это ложная дихотомия для ямы Ant -Ivy против Maven, как это делают многие. Я написал об этом здесь. (Обратите внимание, что после сообщения в блоге Gradle в качестве основного инструмента сборки был заменен Gant.)

Ответ 8

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

Большая часть проблемы сводится к документации. Каноническое руководство часто представляет собой сообщение в форуме или stackoverflow, чтобы ответить на совершенно другую проблему, с которой вы только что столкнулись.

Как это руководство по использованию груза: Запуск внешнего процесса во время тестирования интеграции в maven, который я нашел не с веб-сайта плагина maven-cargo, а только потому, что я оказался для троллинга через stackoverflow.

Но когда вы смотрите на это mojo, а затем на грузовую страницу, действительно ли это понятно для среднего разработчика (читайте меня)?

Возможно, maven похож на капитализм, его худшее, кроме всего остального.

Ответ 9

Я был в шоке: 67% разработчиков не используют Maven. Почему?

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

Есть ли альтернативные инструменты, облегчающие управление проектами?

Google так говорит. Ant, Gradle, Gant, Ivy, Rake, SBT. Я лично одобряю Gradle и Gant над чем-либо еще. SBT может быть свиней, но как только вы его запускаете, он сладок. И я бы использовал Ant над Maven для любого нового или существующего проекта.

Не поймите меня неправильно, я использовал Maven, и я могу с этим справиться. Проблема в том, что это действительно потрясающие вещи с его плагиновой архитектурой. Попробуйте сделать что-то из коробки, и это становится грязной задачей.

Для меня это удивило, когда опытные программисты рассказывают о трудностях Maven, когда я увидел Ant в каком-то проекте Maven показал мне чудо

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

Ant

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

Плохие программисты делают следующее:

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

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

Ant в значительной степени следует модели с именем GIGO: Garbage In, Garbage Out. При создании сценариев Ant вы должны иметь существенное предусмотрительность.

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

Maven

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

Но что происходит, когда у вас есть существующая система, которая не обязательно соответствует архетипу? Что произойдет, если вы хотите или хотите использовать другой макет?

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

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

Если да, то что происходит, когда вам юридически/контрактно требуется использовать репозиторий управления версиями, такой как ClearCase, где вы должны явно проверять вещи до изменения? Инанные материально-технические вещи, которые даже не должны входить в картину, и ум разработчиков закрадывается.

Существуют практические (а также глупые) причины предпочесть Ant над Maven и наоборот. Просто так случается, что раскол примерно на 1/3 в пользу Maven и 2/3 в пользу Ant. Разделение близко напоминает отношение, которое я видел от новых проектов и существующих.

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

Просто так случается, что гораздо больше разработчиков Ant -aware (хорошие и плохие), чем разработчики Maven (хорошие и плохие). Это то, что я бы серьезно рассмотрел.

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

С учетом сказанного я бы использовал Gradle для новой системы (или переписал в нее систему сборки Ant или Maven, если бы у меня были полномочия, а разработчики вокруг меня были, по крайней мере, полукомпенсированы).

Это просто превосходная система сборки по сравнению с Ant и Maven.

Ответ 10

Как уже говорилось, существует высокий барьер входа. Там также много старых проектов, которые уже имеют хорошо установленные скрипты/инструменты сборки. В большинстве случаев нет смысла заменять что-то, что уже работает с maven.

Недостаток/разрозненная документация не помогает - единственный действительно хороший учебник для maven - это полная книга, написанная сонатипом... и это довольно много, чтобы попросить кого-то прочитать, а затем пойти узнать, как работают плагины с единственной целью - создать/управлять pom.xml, чтобы определить, как проект будет создан/управляется.

С учетом сказанного, хотя, maven отличный инструмент (даже если он слишком сложный для собственного блага).

Ответ 11

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

Конечно, Id скорее использует maven, но просто сложно сбиться с земли.

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

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

Ответ 12

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

Я прочитал несколько недель назад о том, кто потратил (это то, что он утверждает) более 500 часов, пытаясь использовать Maven... Вы могли бы написать несколько плагинов Maven и создать свое приложение через 500 часов.

И, кстати, это с открытым исходным кодом, и если вы обнаружите проблему, сообщите об этом или исправьте ее

• Если это действительно проблема, я уверен, что она будет исправлена.
• Если это хорошее предложение, я уверен, что оно будет учтено.

PS. Я не являюсь частью команды Maven, просто обычного пользователя, не более того.

Ответ 13

Я согласен, я не понимаю, почему кто-то, кто использовал Maven, выберет любые другие инструменты.

Я думаю, что неравенство сводится к императивному против декларативного. Программисты начинают изучать императивное программирование, то есть Ant, существует комфортная зона, находящаяся на императивном языке, хотя она требует более длинных файлов script, вы чувствуете, что можете всегда ее менять. Maven является декларативным, вы должны доверять тому, что вещи объявлены правильно, и когда они не работают так, как вы ожидаете, что вы делаете? Это в сочетании с плохо документированными плагинами не помогает. Вот почему популярны другие инструменты, обладающие функциями maven, но использующие императивный стиль.

Я бы сделал тот же аргумент Wicket/Tapestry над JSP, почему в мире кто-то будет использовать JSP script -подобный стиль, когда вы сможете объявлять компоненты для использования? Он возвращается в зону комфорта. Я думаю, что декларативная станет более популярной, и Maven станет одной из тех технологий, которые подталкивают конверт, но по мере того как мы получим масштабируемые на массовом рынке компьютеры, декларативные языки и методы станут более комфортными и стандартными тарифами.

Ответ 14

Maven - отличный инструмент, концепции и мировоззрение, которые он предлагает, - это большой шаг вперед с тех пор, пока мы просто не наклеили ленточный код вместе, чтобы создать программное обеспечение (я сейчас ныряю в устаревшем приложении Deplhi с более 1M LOC.. ho боль... насколько я скучаю по Maven)

Это сказано.. IMHO maven все еще в нем, детство, документация, хотя и намного лучше, чем раньше, все еще мало и трудно попасть. У регулятора плагинов все еще есть несколько перегибов, так как может быть трудно полностью контролировать вашу среду сборки. Также поведение системы по-прежнему сильно меняется от одной версии к другой, поэтому трудно гарантировать стабильные сборки во времени.

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

Несмотря на все это, они находятся на правильном пути, и медленное проникновение, которое он видит, на самом деле является "хорошей вещью", потому что оно будет поддерживать рост системы в пределах управляемых ярости, чтобы проблемы были сглажены вовремя.

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

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

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

... Но это намного больше того.

Короче говоря:

• Maven как инструменты необходимы, но внимательно следите за ним, он Укусит вас, когда он созреет.
• Сохраняйте здоровое разнообразие в своем механизме сборки, чтобы вы всегда могли вернуться к другим более простым методам, если Maven не справляется с этой конкретной потребностью.
• Подпишитесь на новостную группу и много читайте на ней из других источников, написав документы, требующие времени и почти всегда устаревшие, особенно в инструменте, как кровоточащий край, как maven.
• Выживите свои ранние разочарования, ваши усилия будут вознаграждать вас богато вовремя.

Мой 2 цента

Ответ 15

Я кратко работал в компании около 2005 года, которая имела конструкцию Ant с примерно 80 подпроектами. Они признали, насколько важно для команды управлять тестированием и выпуском, поэтому должна быть воспроизводимая сборка, но зависимости модулей были сложными и трудными для любого, кто мог бы визуализировать без графического инструментария.

То, что они делали, было довольно романтичным для времени. Признавая, что они могли проверять метаданные Eclipse и метаданные (как XML), было легко разобрать, они написали плагин Ant, чтобы читать файлы .classpath и составлять зависимости для формальной сборки таким образом.

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

Самое смешное, что они вместе взяли МакГиверед Мейвен и даже не осознали этого.

Эта история важна по нескольким причинам. Во-первых, для магазинов, которые не знают Maven и не собираются становиться большими, Maven может быть переборщиком. Я бы сказал, что сборщики, которые над несколькими десятками модулей становятся трудными без Maven. Во-вторых, хотя Maven может показаться, что он "плохо документирован" и "берет на себя сборку", факт заключается в том, что он больше документации, чем существует для 98% локально построенных пользовательских процедурных сборок. С созданием Maven любой, кто знает Maven, может быть нанят для работы над ним, что является хорошим или плохим в зависимости от вашей перспективы синтетической безопасности работы через внутренние священства. Наконец, хотя многие разработчики звезд используют Eclipse, те, которые этого не делают, не собираются запускать только потому, что у вас есть работа для них. Они часто просто отправляются куда-то еще.

Maven определенно требует инвестиций, чтобы учиться, но, как оказалось, это не больше инвестиций, чем если бы все другие вещи (например, репозитории и документация) учитывались при массивной сборке. Самое главное в этот день и в возрасте - это взаимодействие с Центральным репозиторием Maven, и в конечном итоге это требует POM. Возможно синтезировать POM с помощью таких инструментов, как SBT и Gradle, но если кто-то из группы должен знать, как отлаживать их, чтобы опубликовать что-то, точка не изучает Maven, а какая-то спорная.

Когда-нибудь Maven Central не будет так важна, но до тех пор...

Во всяком случае, есть много причин и против Maven. Это де-факто построено там, иначе другие инструменты сборки там не будут полагаться на Maven Central так, как они это делают.

Ответ 16

С структурой проекта, основанной на Maven, вы можете легко обеспечить SoC (Разделение проблем). Если вы сделаете это неправильно и получите круговые зависимости, maven не будет строить.

Maven, используемый с релизами, разделение проблем и управление зависимостями - это дисциплина.

Если вы хотите "взломать" свой путь вокруг, вы могли бы. Но опять же, я бы предложил использовать Maven как дисциплину. Вы можете вести команду с дисциплиной. Ваша жизнь становится несколько сложнее, если вы примете несколько дисциплин (скажем, вы строите один проект в Maven и один в Gradle).

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

Что касается разработчиков Netbeans, не делайте этого, потому что это делают другие. Это как верить в Бога, потому что другие делают.

Если все находятся на борту, попробуйте Gradle.

Ответ 17

Ну, во-первых, этот опрос вряд ли является точным, учитывая, что вы видели его на странице NetBeans. Если это было проведено NetBeans (в отличие от ссылки from NetBeans), то тем более вероятно, что большое количество разработчиков not, запущенных NetBeans, пропустит это. Использование Maven ниже по сравнению с Ant, но насколько меньше нигде не известно.

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

Ответ 18

Что касается альтернатив, единственное, что я знаю, помимо доморощенной системы, использующей Ant, - Apache Ivy

Ответ 19

Моя проблема с Maven заключается в том, что одна из основных вещей, которую она делает, - не лучшая практика. Maven выйдет и загрузит новейшую версию любой зависимости, которую вы имеете. Хотя это звучит хорошо, это плохая практика. Мне нужны зависимости для моего проекта в моем проекте, потому что я не хочу, чтобы у каждого разработчика были разностные версии файлов jar, и я определенно не хочу, чтобы непроверенные зависимости использовались при развертывании в prod.

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

Да, я знаю, что в моем проекте можно разместить репозиторий зависимостей и использовать его в проекте, но это огромная боль. Я просто хочу папку lib в моем проекте и сказать maven, что это банки, которые я использую. период. Я бы скорее написал файл ant build.xml, чем тратить много раз на создание pom.xml файлов.

Ответ 20

Я думаю, что maven похож на объектно-ориентированное программирование, поскольку его трудно освоить после многолетнего структурированного программирования, но он имеет сильные преимущества по отношению к императивным инструментам, таким как Ant. Мне нравится maven, хотя я должен признать, что мне потребовалось около 3 дней, чтобы выучить его на неудобном уровне и реализовать его с существующими проектами wcl-проекта eclipse с зависимыми проектами и множеством внешних банок, а также с eclipse и m2e. После того, как выучились и внедрены, теперь это намного проще и гораздо более чистым и организованным.

Я думаю, что Maven был широко принят, и я должен не согласиться с утверждением, что "так мало людей используют Maven". Если один googles для MVN Respository или посетите сайт SpringSource.org, вы узнаете, сколько полезных библиотек и проектов построено с помощью Maven.

Ответ 21

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

Maven, с другой стороны, работает со стандартной моделью сборки, которую вы сопоставляете с вашим кодом.

Его довольно мощный, но не простой в использовании. Его лучшая функция - удаленные репозитории, и теперь это возвращается к другим типам инструментов сборки.

Ответ 22

Maven делает менеджеров проектов и других (не девелоперских) человеческих вмешательств устаревшими. Так почему бы не? Хорошо, есть некоторые проблемы и некоторые недостатки, но пока только плющ становится достаточно близко. Предстоящие выпуски должны включать в себя генерацию функционального анализа Mojo или даже расширенную интеграцию платформ непрерывной сборки и систему Mojo's. Лично я действительно очень люблю процесс grails для обработки зависимостей проектов и плагинов с того времени. Просто любите его.

Ответ 23

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

Я только проблема, я вижу, что документация не так уж хороша, но со временем улучшится.

Надеюсь, это поможет. Краткая информация о Maven, сравнение между Ant и Maven

Ответ 24

EBuild является современной альтернативой Maven.

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

Он просто управляет/строит все ваши проекты для вас. Вы проверяете проект, а ebuild обрабатывает остальные. Он извлекает все зависимости и создает их. Когда вы будете готовы к выпуску, релиз script затем создает сборку для вас.

В настоящее время он предназначен для использования с Eclipse и работает только с SVN (разработан с намерением поддерживать другие SCM, такие как GIT и т.д.).