Я видел, как многие компании пытались мигрировать из Ant в Maven с переменным успехом. Существует изменение в мышлении, которое должно произойти при переходе. Вот некоторые из основных моментов.
Стандартные выводы
Монолитная конструкция
Это первый большой сдвиг в мышлении. Типичные (очевидно, не ВСЕ) проекты Ant работают путем синхронизации некоторого огромного объема кода из системы управления исходным кодом, вставки компакт-диска в какой-либо каталог верхнего уровня, а затем приказания Ant создать только тот модуль, который вы планируете тестировать. Что так плохо об этом , вы можете спросить? Ну, во-первых, вы, вероятно, синхронизируете большие объемы кода, которые никогда не будете запускать локально. Вы, вероятно, создаете (и юнит-тестирование, верно?) Пакеты, которые не меняются или скорость их изменения также очень низка. В идеале эти пакеты и библиотеки должны быть созданы для пользователя. Теперь посмотрите на это , скажем ,глаза webdev. Если ваша группа webdev отвечает за такие вещи, как изменения CSS, HTML или JSP, почему они должны беспокоиться о создании вашего пакета oodles-of-utils? Или , если тестовый модуль начинает сбиваться на них (ты модульное тестирование , не так ли?), Почему они должны изучить и выяснить , что отсутствует или мели н . В идеальном мире любой уровень развития может заменить другой (насколько было бы здорово, если бы все знали все?). В реальном мире, с перерывами, семьями и сроками, это нереально (особенно в крупных компаниях).
Поэтому лучше всего выводить из эксплуатации монолит по нескольку модулей за раз , когда вы решили пойти по пути Maven . Есть два способа сделать эту работу. Вы можете использовать атомарный подход «все или ничего»; Переход от монолита к более модульной кодовой базе одним махом. Если вы можете подписать это, то это замечательная вещь. Я должен был сдерживать и себя и других от откусить слишком много. Что мне нравится делать, так это вытаскивать сразу несколько вещей, может быть, три-четыре модуля. Из этих четырех пусть три будут библиотеками с низким циклом и одна библиотека с высоким циклом. Таким образом, люди узнают новое расположение частей, составляющих ваши библиотеки, которые объединены в единое целое. Думай об этом большекак эволюционный процесс против революционного процесса.
Имея меньший укус — размер кусков также лучший способ узнать Maven . Если вы познакомите людей с массивным монолитом с настройками повсюду с дюжиной прикрепленных сборок, то люди будут тыкать в него палкой и быстро его ненавидят. Четкое представление о том, как работает веб-приложение и как создается созданный в результате артефакт, намного удобнее , и вы получите меньше жалоб на реализацию Maven .
Нужно все строить всегда (так как все всегда меняется)
Еще один страх, который возникает, когда люди начинают задумываться о модульности, этос несколькими развертываемыми блоками, как кто-нибудь узнает, что совместимо с другим внутренним кодом, когда процесс не всегда все время строит одно и то же? Ну, на это можно ответить несколькими способами, но самый простой ответ — когда библиотека выпущена (или иным образом заморожена) для развертываемого модуля, тогда этому развертываемому модулю не нужно обновлять свою версию этой библиотеки. Если общая функциональность библиотеки изменится, вам придется провести повторное тестирование, но возникает вопрос — правильный ли код вашего приложения в модуле? Разве общий модуль не должен оставаться несколько универсальным, и каждый развертываемый модуль расширяет / реализует эти функции вместо того, чтобы внедрить эту логику на таком низком уровне? Я обнаружил, что со временем, если вы сделаете библиотеку отдельным модулем от более крупных сборок развертываемых модулей,код начинает мигрировать в правильном направлении по сравнению с тем, где его проще всего добавить (не нужно больше массивного поиска / замены в базе кода через IDE).
Путаница в отношении создания артефактов
Как только все вытащено, со стороны разработчика может возникнуть путаница в отношении того, какие модули должны быть построены в каком порядке. Это для меня образовательная вещь. В любой момент разработчик может запустить «mvn dependency: tree» и посмотреть:
— Какие зависимости составляют их проект
— Откуда эти зависимости были разрешены
— В каком порядке они должны быть построены
При переходе из мира, в котором люди работают с каталогами очень высокого уровня и строят все, в мир, где каждый модуль очень легкий и каждый шаг тактический, люди часто не знают, как запустить этот сервер приложений или что-то подобное. демон работает локально. Поскольку каждое приложение представляет собой отдельную автономную сборку, пользователям просто нужно синхронизировать то, что они хотят запустить, и в остальном полагаться на менеджер хранилища (биты сервера приложений, биты базы данных и т. Д.).
Ярлыки для управления хранилищем
Менеджер хранилища является частью процесса Maven 2, конец истории. Попытка использовать корпоративный общий доступ к файлам или заставить всех работать в автономном режиме — это не способ Maven . Использование менеджера репозитория также помогает минимизировать конфигурацию, которой людям придется управлять локально в своем файле settings.xml, а также помогает внедрить образ жизни Maven (запрет повторных развертываний, перенос выпусков в один репозиторий и моментальных снимков в другой, отсутствие удаления артефактов и т. Д.). ). С чем-то вроде одной из большой тройки ( Nexus , Archiva , Artifactory), у вас просто есть сгруппированное хранилище, на которое все указывают. Этот «сгруппированный» репозиторий является представлением всех других репозиториев, которые будет использовать ваша компания. Таким образом, вы можете получить что-то вроде этого:
<snip>
<mirrors>
<mirror>
<id>nexus-test</id>
<mirrorOf>*</mirrorOf>
<url>http://server/nexus/url</url>
</mirror>
</mirrors>
<profiles>
<profile>
<id>nexus-test</id>
<repositories>
<repository>
<id>central</id>
<url>http://central</url>
<releases><enabled>true</enabled></releases>
<snapshots><enabled>true</enabled></snapshots>
</repository>
</repositories>
<pluginRepositories>
<pluginRepository>
<id>central</id>
<url>http://central</url>
<releases><enabled>true</enabled></releases>
<snapshots><enabled>true</enabled></snapshots>
</pluginRepository>
</pluginRepositories>
</profile>
</snip>
Вот и все. Этот параметр охватывает каждый удаленный репозиторий, который мы используем — от Codehaus до Repo1. Если вы действительно амбициозны, хотя Sonatype не рекомендует этого , вы можете даже привести в порядок URL, поэтому, если вы переключаете менеджеры репозитория, разработчикам не нужно трогать их файл settings.xml. Хотя эту конфигурацию можно свернуть в файл MAVEN_HOME / conf / settings.xml, я лично хочу, чтобы моя конфигурация была независимой от maven-version (помещая ее в версию файла settings.xml моего домашнего каталога).
Пользовательские вещи, сделанные в Ant, которые (считается) не могут быть выполнены в M2
У каждого есть один маленький темный уголок своего строительного мира. Обычно это был быстрый взлом, чтобы заставить вещи работать через Ant . Возможно , задача выполняется или , возможно , некоторые оболочки из , или что — то сумасшедшее. Эти маленькие темные уголки должны были пролить свет на них, фактически, залить их светом. Вместо того, чтобы допустить, что это станет проблемой , начните с поиска в общих репозиториях плагинов, которые делают то, что вы ищете. Есть очень мало проблем, которые кто-то еще еще не решил, и даже если вы искали некоторое время назад, решение может существовать сейчас, чего не было тогда. В прошлом я проводил исчерпывающие поиски и не нашел ни одного плагина, который бы отвечал моим потребностям. Тогда я нахожу такмой плагин изменился несколько месяцев спустя, чтобы сделать именно то, что я искал , или кто-то написал его и отправил обратно в google / codehaus / repo1. Если этот маршрут не подходит, просто создайте подключаемый модуль Maven 2 и разверните его в своем локальном хранилище. Вы даже можете иметь переходный период, когда Maven вызывает Ant для выполнения этой небольшой операции, затем перемещает задачи Ant в Maven 2 , а затем, наконец, мигрирует в плагин Maven 2. Не используйте аргумент, что «вы должны писать код, а не Maven 2 plug-in”. Do you want your system to be robust and clear when there are successes and failures? Then write the plug-in. You can start quickly by typing “mvn archetype:generate”, then select “maven-archetype-mojo” (option 12 as of this writing).
Other things to consider when moving to Maven
CI compatibility – some are designed around Maven
The original cruise control’s Maven integration was very poor (I’d say the opensource version is still pretty bad). It doesn’t understand the different life-cycles or the output from each. Hudson understands the life-cycles, and will inherently do things depending on what it sees in the build output. So far in my travels and exploration of various CI servers/tools, Hudson is head and shoulders above the rest with regard to Maven integration. Have site output you’d like to share? Maven can publish that quickly with a link off of your project’s page. You have artifacts you’d like made available to another downstream job (or later process)? Hudson picks up on those artifacts and tucks them away (maybe/maybe not to your liking). All other products need to have these various things called out, you need to tell them, “look here for this tar.gz file” versus knowing based upon what Maven has logged.
Lack of understanding of how to upgrade (from one version of Maven to another)
Here’s another big disconnect, you can’t just fling a new version of Maven down like you could with Ant. With Ant, you could generally look at the release notes, then install and add your custom tasks and then build. With Maven 2, for the most part, you’re protected from a lot of things, but you also need to watch for plugin versions, core changes to dependency resolution, etc.. I personally sleep better installing locally and building, then diffing against the artifacts that are generated by the build server. Some changes to Maven (2.0.5 to 2.0.6) required users to review their dependencies for example.
Should you move to Maven 2?
Well, that question is best answered by you, dear reader. If you can modularize your codebase, then you’ll see the biggest improvement both in development time (better throughput) as well in stability – no more broken unittests that when fixed, reveal more broken unittests ultimately convincing all developers to turn them off. If you can’t (or don’t see any benefit), I’d submit your development team isn’t mature enough to realize the many benefits to a highly modular codebase. In the end, you have to choose what gets product out the door.
(image via ePublicist)