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

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

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

Мой план состоял или должен был перенести весь проект из Ant в Maven, так как планируются новые компоненты, и я хотел бы избежать этих проблем в будущем и хорошо, потому что это просто ужасно, как сейчас ;-)

Поскольку я новичок в переносе более крупных проектов, меня немного смущает лучший рабочий процесс. Здесь задействованы десятки XML файлов и сценариев, которые распространяются в не-Maven структуре каталогов. Всего задействовано более 3000 файлов. Одна из основных проблем заключается в том, что я не знаю, действительно ли мне следует пытаться перенести все в известной структуре каталогов Maven и, следовательно, рисковать бесконечным редактированием и рефакторингом каждого отдельного файла. Или я должен сохранить структуру папок, как она есть, и раздуть мои файлы pom.xml и, возможно, столкнуться с проблемами со всеми различными подключаемыми плагинами? Честно говоря, оба способа не кажутся достаточно конструктивными.

Имеет ли смысл даже перенос проекта в этом измерении в Maven? Особенно когда SOA-фреймворк должен использовать свои собственные файлы Ant - поэтому будет необходимо сочетание 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 моей структуры проекта.