Думая об изучении Maven

Question

У меня есть побочный проект, который я делаю = на Java. Это довольно простое веб-приложение. Он работает в Tomcat на сервере Linux и использует базу данных MySQL. Большая часть кода была написана с использованием Spring Framework. У него много юнит-тестов. Когда я пишу код, это в Eclipse. При развертывании приложения я запускаю несколько сценариев оболочки, чтобы переместить файл WAR на веб-сервер, выполнить обновления базы данных и внести изменения в конфигурации Apache. Я единственный разработчик, работающий над этим, и сейчас он развернут только в 1 среде (производственной), хотя когда-нибудь я также захочу иметь среду тестирования или промежуточной среды. Я использую контроль версий SVN через плагин Eclipse.

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

Answer 1

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

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

Другая большая победа, которую дает вам Maven, - это управление зависимостями. Вы можете декларативно определить зависимости вашего проекта в конфигурационном файле Maven, который называется Project Object Model (POM), и Maven выполняет работу по сохранению всех jar-файлов в структуре локального каталога, которую он поддерживает. В случае общедоступных артефактов банки автоматически загружаются из центрального репозитория Maven, а в случае внутренних или проприетарных файлов сторонних производителей вы можете установить их в свой репозиторий с помощью одной команды.

В дополнение к простой организации этих артефактов и автоматической настройке пути к классу сборки для включения всех необходимых jar, maven также будет управлять иерархиями зависимостей. Это означает, что если ваш проект зависит от jar A, а A зависит от jar B, jar B будет автоматически связан с вашей WAR, даже если вы явно не перечислили его как зависимость в конфигурации сборки.

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

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

Answer 2

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

Модульные тесты: Плагин maven surefire

Интеграция Eclipse: m2eclipse

Развертывание файла WAR: Плагин WAR и Плагин развертывания

Maven также может помочь вам в интеграционных тестах на Tomcat (если они у вас есть), поскольку вы можете начать, остановить или развернуть войну с помощью грузового плагина .

В любом случае, если вы планируете читать в свободное время, вот бесплатная книга (в формате PDF): Maven полное руководство

Надеюсь, это поможет!

Answer 3

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

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

Answer 4

Однажды я начал новую временную работу, которая использовала Maven. Сгорел 2 дня, пытаясь понять, как работала их сборка. Оказалось, что они все использовали maven 1.01 на окнах, и я случайно попытался сделать ставку на 1.02, поэтому у меня это не сработало. Никто не знает, как это работает, и они использовали его в течение нескольких месяцев, и они были довольны этим. Несколько месяцев спустя в том же проекте мне пришлось углубиться в jelly-скрипты, чтобы изменить одну переменную сборки. Это было не весело.

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

Мое мнение:

• любой инструмент, который вы используете, но который вы не совсем понимаете, является ошибкой и потенциальной опорой для вашего процесса разработки. Если инструмент действительно очень сложный, вы, скорее всего, будете использовать его простейшие части, а не углубленно его осваивать. Если вы не используете и не уклоняетесь от самых мощных частей инструмента, скорее всего, вы побеждаете цель его использования.
• Maven - классический пример чего-то настолько полного автоматизма, что вы не понимаете, что он делает, если только вы не посвящаете гораздо больше своего времени, чем тот инструмент сборки, который заслуживает того, чтобы стать maven maven. Чрезмерно спроектированное решение в поисках проблемы.
• Я не нашел ни одного примера того, что мне нужно было сделать, чего бы я не мог сделать с муравьем, и для чего мне был нужен мавен. Я знаю, что есть, я просто никогда не нуждался в них. Если бы я это сделал, я, вероятно, был бы более благотворительным в отношении усилий, необходимых для борьбы с maven.
• Это делает вашу сборку зависимой от интернета. Сейчас нередко скачивать небольшой проект, запускать mvn и загружать 10 плагинов maven, прежде чем он даже начнет создавать то, что вы пытаетесь построить в первую очередь. Что это делает? На самом деле нет способа узнать, но вам лучше надеяться, что это не сломается. Когда происходит сбой, сложность сбоя и сложенные уровни зависимостей делают его практически безнадежным для отладки. Я не понимаю, почему это является улучшением простых инструментов сборки или даже желательно по любой причине.

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

Answer 5

Ваш проект не похож на проект, подходящий для Maven. Кажется, у вас есть рабочая среда разработки. Зачем устанавливать еще один? Он просто предоставит вам еще один файл проекта для поддержки, который нарушает принцип доброй воли DRY .

Answer 6

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

Answer 7

Помимо того, что многие проекты oss используют (или конвертируют в) maven, а некоторые проекты с закрытым исходным кодом переходят в maven, ваш проект НЕ обязательно выигрывает от использования Maven.

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

Некоторые из важных преимуществ maven (jar-зависимостей) можно получить с помощью плюща (http://ant.apache.org/ivy/).

)

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

BR
~ A

Answer 8

Не. Посмотрите, что другие говорят , и внимательно изучите. Также рассмотрите некоторые другие мои комментарии по Maven здесь, на SO.

Answer 9

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

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

Answer 10

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

Однако проще всего было бы просто спросить кого-то, кто уже знает mvn, чтобы он мог показать вам, как он работает, а затем вы довольно быстро его освоите.