Можно ли вставить зависимость модуля в начало пути к классам в каком-нибудь профиле maven?

Question

Я пытаюсь переместить зависимость jmockit-cover-0.994.jar из проекта в какой-то профиль, по умолчанию неактивный, но не могу вставить его в начало пути к классам результатов из зависимостей профиля.

Answer 1

Начиная с Maven 2.0.9, естественный порядок зависимостей действительно сохраняется при построении пути к классам, как указано в заметках о выпуске из 2.0.9:

MNG-1412 / MNG-3111 введено детерминированное упорядочение зависимостей на пути к классам. В прошлом использовалось естественное упорядочение множеств, что приводило к странным результатам. Порядок теперь сохраняется из вашего pom, с зависимостями, добавленными наследованием, добавленным последним. В сборках с конфликтующими или дублирующимися зависимостями это может привести к изменению выходных данных. Короче говоря, если у вас странные проблемы с 2.0.9, взгляните на зависимости, чтобы увидеть, есть ли где-нибудь конфликты.

Так, играя в порядке зависимостей в POM, вы на самом деле можете манипулировать classpath (это может стать немного сложнее, когда вы играете с профилями, но, поскольку вы не предоставили подробную информацию о реальной проблеме, трудно дать больше указаний).

Answer 2

Начиная с версии 2.0.9 Maven упорядочивает ваши зависимости так же, как они перечислены в вашей поме. При этом, как только вы начинаете объединять зависимости из профилей, все становится нетривиальным. Возможно, вы захотите проверить эффективную цену, чтобы увидеть, как выглядит заказ:

mvn help: эффективный pom -Pprofile

Если получится плохо, то одним из способов будет использование зависимости : build-classpath . Другим решением было бы использование областей вместо профилей для выполнения включения.

Answer 3

Извините за множество ответов на свой вопрос ...

Но теперь нет необходимости в хитрости с maven deps, потому что запуск jmockit-покрытия теперь можно настроить с помощью свойства системы См. примечания к выпуску версии 0.955 и , связанных с проблемой 22 * ​​1006 *.

Answer 4

Я откатил взлом, который использовал активный профиль выше, потому что нашел более элегантный способ решить мою проблему.

Источником проблемы была транзитивная зависимость из-за использования некоторых моих модулей testutils с зависимостью области компиляции от JUnit (которая должна быть после JMockit в classpath), тогда как в родительской POM тестовые зависимости были определены следующим образом:

...
<dependencies>
    <dependency>
        <groupId>mockit</groupId>
        <artifactId>jmockit</artifactId>
        <version>0.994</version>
        <scope>test</scope>
    </dependency>
    <dependency>
        <groupId>junit</groupId>
        <artifactId>junit</artifactId>
        <version>4.7</version>
        <scope>test</scope>
    </dependency>
</dependencies>
...
    <profiles>
    <profile>
        <id>coverage</id>
        <dependencies>
            <dependency>
                <groupId>mockit</groupId>
                <artifactId>jmockit-coverage</artifactId>
                <version>0.994</version>
                <scope>test</scope>
            </dependency>
        </dependencies>
    </profile>
...

Найденное решение заменяет область действия JUnit с тестовой на предоставленную.

Это лучший трюк?