Как мне поделиться Maven DepdendencyManagement из нескольких источников?

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

В качестве примера: мой родительский POM может иметь запись, например. commons-codec:commons-codec 1.4, мой POM "core-lib" включает его в качестве зависимости (без явной версии), и я хочу убедиться, что мой модуль упаковки входит в правильную версию. Однако конкретный тип пользовательской упаковки, который я использую, также требует, например. log4j:log4j 1.2.15, и я хочу убедиться, что при запуске моего модуля упаковки он также включает правильную версию log4j.

Вот загвоздка: пример POM, с которым я работаю для «проекта, который создает {индивидуальную упаковку}», использует родителя, предоставленного командой пользовательской упаковки. Если я использую их родителя, я теряю информацию о версии для commons-codec. Если я использую своего родителя, я теряю информацию о версии для log4j.

Теперь, обычно, если я спрашиваю "как сделать так, чтобы A и B зависели от одной и той же версии", вы бы ответили: "сделать так, чтобы A и B имели один и тот же родитель, и включить dependencyManagementsection в родителя". Моя проблема в том, что мне нужно, чтобы A, B и C зависели от одной и той же версии, но у меня нет никакого контроля над C.

Я думаю, это то, для чего предназначены "примеси" Maven, но, конечно, их пока не существует. Тем временем я выбираю одного родителя, затем копирую и вставляю раздел dependencyManagement из другого POM с комментарием «убедитесь, что вы поддерживаете это в актуальном состоянии». Очевидно, это уродливый, уродливый хак, но я не нашел другого способа быть в курсе обеих сторон.


person Coderer    schedule 28.09.2011    source источник


Ответы (3)


Как насчет использования плагина сборки для упаковки вашего артефакта со всеми его зависимостями и вместо этого вместо этого работает ваш модуль упаковки? Тогда вы не пытаетесь использовать магию помпонов. Просто один проект использует артефакт из другого проекта, как обычно.

person Ryan Stewart    schedule 29.09.2011
comment
Вы имеете в виду, что A — это библиотека, B делает из библиотеки jar-с-deps, затем C распаковывает артефакт из B и переупаковывает его в нашу собственную упаковку? Может просто быть достаточно сумасшедшим, чтобы работать; я посмотрю на это - person Coderer; 30.09.2011
comment
Мне приходит в голову мысль: предположим, A (библиотека) имеет общую зависимость с C (пользовательская упаковка / среда выполнения) - может быть, я использую log4j в своей бизнес-логике, а они используют его в своей оболочке демона или что у вас есть. Не могли бы мы включить две версии, используя ваш метод? - person Coderer; 30.09.2011
comment
1) Вам не нужен отдельный B, чтобы сделать jar-with-deps. Просто настройте плагин сборки в A. 2) Если A и C имеют конфликты зависимостей, а C не может об этом позаботиться, возможно, вам следует использовать лучший демонизатор. Именно по этой причине путь к классам вашей оболочки/контейнера должен быть полностью отделен от пути вашего приложения. То есть я не вижу в этом проблемы, которую нужно решить в ваших POM. - person Ryan Stewart; 01.10.2011

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

person Coderer    schedule 11.10.2011

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

person Kango_V    schedule 11.01.2012
comment
Я не думаю, что профили имеют какое-либо отношение к этому. Предположим, у меня есть два проекта (назовем их A и B), и я хочу, чтобы они оба использовали AwesomeLogger v1.2.3. Однако каждый из них должен быть упакован в MySuperContainer. Теперь предположим, что самый простой способ создать пакеты MySuperContainer — сделать MSC parent-POM родителем проекта. Если я сделаю это, не будет возможности иметь декларацию в одном файле POM где-нибудь, говорящую об использовании AwesomeLogger 1.2.3 как для A, так и для B. - person Coderer; 12.01.2012