Из перечисленных вами зависимостей следующие определены как optional в помете activemq-core (см. Также соответствующий раздел из книги Maven).
- org.apache.derby: котелок
- org.apache.geronimo.specs: Джеронимо-jta_1.0.1B_spec
Я не видел прямой зависимости от Jetty, поэтому она может быть транзитивно включена из одной из необязательных зависимостей.
В Maven необязательные зависимости обрабатываются автоматически. По сути, любая зависимость, которая объявлена необязательной, должна быть повторно объявлена в вашем pom, чтобы ее можно было использовать. Из документации, указанной выше:
Дополнительные зависимости используются, когда на самом деле невозможно (по какой-либо причине) разделить проект на подмодули. Идея состоит в том, что некоторые зависимости используются только для определенных функций в проекте и не понадобятся, если эта функция не используется. В идеале такая функция должна быть разбита на подмодуль, который зависит от проекта основной функциональности ... этот новый подпроект будет иметь только необязательные зависимости, так как они вам понадобятся, если вы решите использовать функциональность подпроекта.
Однако, поскольку проект не может быть разделен (опять же, по любой причине), эти зависимости объявляются необязательными. Если пользователь хочет использовать функциональность, связанную с необязательной зависимостью, он должен будет повторно объявить эту необязательную зависимость в своем собственном проекте. Это не самый очевидный способ справиться с этой ситуацией, но опять же и необязательные зависимости, и исключения из зависимостей являются решениями с ограничением.
Я не уверен, что вы можете настроить Ivy на игнорирование необязательных зависимостей, но вы можете настроить его на исключить зависимости . Например:
<dependency name="A" rev="1.0">
<exclude module="B"/>
</dependency>
Это не совсем удовлетворительно, я знаю. Возможно, что Ivy поддерживает необязательные зависимости (я еще посмотрю и обновлю, если что-нибудь найду), но механизм исключений, по крайней мере, позволяет вам управлять ими.
Относительно последней части вашего вопроса. Maven разрешит версии зависимостей для log4j и, если версии совместимы, он автоматически выберет «ближайшую» из перечисленных версий.
Из Введение в механизм зависимости :
Посредничество зависимости - это определяет, какая версия зависимости будет использоваться при обнаружении нескольких версий артефакта. В настоящее время Maven 2.0 поддерживает только использование «ближайшего определения», что означает, что он будет использовать версию ближайшей зависимости к вашему проекту в дереве зависимостей. Вы всегда можете гарантировать версию, явно объявив ее в POM вашего проекта. Обратите внимание, что если две версии зависимостей находятся в одной и той же глубине в дереве зависимостей, до Maven 2.0.8 не было определено, какой из них выиграет, но начиная с Maven 2.0.9 учитывается порядок в объявлении: выигрывает первое объявление.
- «ближайшее определение» означает, что используемая версия будет ближайшей к вашему проекту в дереве зависимостей, например. если зависимости для A, B и C определены как A -> B -> C -> D 2.0 и A -> E -> D 1.0, то D 1.0 будет использоваться при построении A, поскольку путь от A до D через Е короче. Вы можете явно добавить зависимость к D 2.0 в A, чтобы принудительно использовать D 2.0
Если версии несовместимы, у вас есть большая проблема, чем разрешение зависимостей. Я считаю, что Айви работает на похожей модели, но я не эксперт.