Перенос сложного проекта из Ant в Maven - Как обрабатывать необычные структуры папок?

Ответ 1

Вот простой и быстрый ответ на проект Mavenizing Ant:

НЕ ДЕЛАЙТЕ ЭТОГО!

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

Проблема в том, что Ant позволяет разработчикам делать дикие и безумные вещи, которые вы должны полностью переделать в Maven. Это больше, чем просто структура каталогов. Муравей допускает множество артефактов сборки. Maven позволяет только один на pom.xml ¹. Что если ваш Ant-проект создает полдюжины разных jar файлов, и эти jar файлы содержат много одинаковых классов? Вам придется создать полдюжины проектов Maven только для jar файлов, а затем еще полдюжины для файлов, которые являются общими для jar файлов.

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

Разработчики не хотели этого делать, поэтому мне выпал CM. Я провел шесть месяцев, переписывая все в Maven. У нас был WSLD, у нас был Hibernate, у нас были различные фреймворки, и каким-то образом мне пришлось все реструктурировать, чтобы заставить его работать в Maven. Я должен был породить новые проекты. Я должен был перемещать каталоги. Мне пришлось придумывать новые способы ведения дел, и все это не мешало разработчикам делать огромные объемы разработки.

Это был самый внутренний круг ада.

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

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

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

Добавление проекта в текущую систему сборки не было слишком сложным:

• Мне пришлось добавить несколько строк в build.xml чтобы интегрировать наш проект ivy.dir в текущий проект.
• Я должен был определить файл ivy.xml для этого проекта.
• Я изменил любой экземпляр <jar and </jar> на <jar.macro и </jar.macro>. Этот макрос делал все, что делала стандартная задача <jar/>, но он также встраивал pom.xml в jar, как это делают сборки Maven. (У Ivy есть задача для преобразования файла ivy.xml в pom.xml).
• Я вычеркнул всю старую чушь управления зависимостями, которую добавил другой разработчик. Это может уменьшить файл build.xml на сто строк. Я также разорвал весь материал, который делал проверки и коммиты, или ftp'd или scp'd вещи поверх. Все это было для их системы сборки Jenkins, но Jenkins может справиться с этим без помощи файлов сборки, спасибо.
• Добавьте несколько строк для интеграции Ivy. Самым простым способом было удалить файлы ivy.xml каталога lib, а затем просто загрузить их через ivy.xml. В целом, для этого может потребоваться добавить или изменить дюжину строк кода в build.xml.

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

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

Кстати, наиболее полезным инструментом для этого процесса является Beyond Compare. Это позволило мне быстро убедиться, что новый процесс сборки совместим со старым.

В любом случае переходим на Maven...

Самое смешное, что после того, как вы интегрировали свои проекты Ant с Ivy, превратить их в проекты Maven не так сложно:

• Очистите логику в вашем build.xml. Возможно, вам придется переписать его с нуля, но без большей части мусора управления зависимостями это не так уж сложно.
• После очистки build.xml начните перемещать каталоги, пока они не будут соответствовать структуре Maven.
• Измените источник, чтобы соответствовать новой структуре каталогов. У вас может быть WAR, который содержит * css файлы в нестандартном месте, и код жестко привязан к этим файлам в этом каталоге. Возможно, вам придется изменить свой Java-код, чтобы он соответствовал новой структуре каталогов.
• Разбейте Ant-проекты, которые строят несколько проектов, на отдельные Ant-проекты, каждый из которых создает один артефакт.
• Добавьте pom.xml и удалите build.xml.

¹ Да, я знаю, что это не совсем так. Есть проекты Maven с подпроектами и супер-помпами. Но у вас никогда не будет проекта Maven, который собирает четыре разных несвязанных фляги, хотя в Ant это довольно распространено.

Ответ 2

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

Мне действительно нужно было установить <sourceDirectory> и <outputDirectory> и, возможно, добавить фильтры включения и исключения, но, в конце концов, я бы сказал, что даже если Maven-путь действительно условно- config-ish и упрощает вашу жизнь, если вы следуете его директивам о том, где разместить файлы, на самом деле это не делает их намного сложнее, если вы этого не сделаете.

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

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