Использует ли maven-dependency-plugin какой-либо другой вид разрешения артефактов, чем остальная часть maven? - PullRequest
10 голосов
/ 03 августа 2009

Если я использую плагин maven-dependency-plugin, то я не могу использовать диапазон версий. Также кажется, что версия определенного там артефакта не обновляется, хотя в удаленном хранилище находится более новая версия.

Почему это так?

Использует ли maven-dependency-plugin какой-то другой механизм, чем остальная часть maven, для разрешения зависимостей? И если это так, то почему?

Вот пример:

Я создал проект org.example: org.example.simple.project1: jar и поместил его в хранилище, используя версии 1.0.0-SNAPSHOT, 1.0.0, 1.0 .1 и 1.1.0-SNAPSHOT

Теперь я настроил подключаемый модуль зависимости следующим образом:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-dependency-plugin</artifactId>
    <executions>
        <execution>
            <id>unpack-stuff<id>
            <phase>initialize</phase>
            <goals>
                <goal>unpack</goal>
            </goals>
            <configuration>
                <artifactItems>
                    <artifactItem>
                        <groupId>org.example</groupId>
                        <artifactId>org.example.simple.project1.</artifactId>
                        <version>[1.0,1.1)</version>
                        <type>jar</type>
                        <overWrite>true</overWrite>
                        <outputDirectory>target/stuff</outputDirectory>
                        <includes>**/*.*</includes>
                    </artifactItem>
                </artifactItems>
            </configuration>
        </execution>
    </executions>
</plugin>

Если разрешение зависимостей будет таким же, как и в других зависимостях, версия должна разрешить (по крайней мере, на мой взгляд) значение 1.0.1 .

Вместо этого я получаю следующее исключение:

[ERROR] FATAL ERROR
[INFO] ------------------------------------------------------------------------
[INFO] version was null for org.example:org.example.simple.project1.
[INFO] ------------------------------------------------------------------------
[INFO] Trace
java.lang.NullPointerException: version was null for org.example:org.example.simple.project1.
at org.apache.maven.artifact.DefaultArtifact.getBaseVersion(DefaultArtifact.java:362)
at org.apache.maven.artifact.repository.layout.DefaultRepositoryLayout.pathOf(DefaultRepositoryLayout.java:47)
at org.apache.maven.artifact.repository.DefaultArtifactRepository.pathOf(DefaultArtifactRepository.java:110)
at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:125)
at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:74)
at org.apache.maven.plugin.dependency.fromConfiguration.AbstractFromConfigurationMojo.getArtifact(AbstractFromConfigurationMojo.java:242)
at org.apache.maven.plugin.dependency.fromConfiguration.AbstractFromConfigurationMojo.getProcessedArtifactItems(AbstractFromConfigurationMojo.java:143)
at org.apache.maven.plugin.dependency.fromConfiguration.UnpackMojo.getProcessedArtifactItems(UnpackMojo.java:138)
at org.apache.maven.plugin.dependency.fromConfiguration.UnpackMojo.execute(UnpackMojo.java:88)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:453)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:500)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:479)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:331)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:292)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:301)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 4 seconds
[INFO] Finished at: Mon Aug 03 17:21:41 CEST 2009
[INFO] Final Memory: 13M/133M
[INFO] ------------------------------------------------------------------------

Ответы [ 4 ]

20 голосов
/ 28 октября 2009

Хорошо, вот реальный ответ (я написал плагин зависимости):

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

Гораздо лучший подход - использовать формы этих целей для xxx-зависимостей. Эти цели требуют, чтобы Maven выполнил разрешение до того, как они были вызваны, поэтому он на 100% совместим. Вы можете использовать фильтры, такие как groupId и artifactId, чтобы эффективно получить список нужных артефактов, и конечный результат будет таким же.

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

Все это говорит о том, что в Maven 3 код разрешения окончательно полностью отделен ... плагин зависимостей, управляющий большинством сценариев использования, необходимых для этого. Я начну работать над новой версией плагина, чтобы полностью использовать это в ближайшее время ... и хотя для этого потребуется maven 3, он, наконец, будет работать на 100% со всеми целями.

2 голосов
/ 03 августа 2009

Плагин зависимости использует тот же механизм разрешения, что и все остальное. Возможно, ваши репозитории не обновляют метаданные, потому что для них установлено значение никогда или еженедельно или что-то еще. Вы можете заставить Maven обновить все метаданные удаленного репозитория, запустив -U.

Плагин зависимостей также не перезаписывает загруженные зависимости по умолчанию, если они уже существуют в целевом объекте. Вы можете сделать чистку или настроить цель, чтобы принудительно перезаписать. Есть три параметра, которые можно установить в true: overWriteIfNewer , overWriteReleases и overWriteSnapshots . Подробнее см. в документации .

Редактировать: в зависимости от вашего обновленного вопроса проблема в том, что вы используете диапазон зависимостей. Диапазоны хороши, если есть что-то, чтобы разрешить версию (например, у вас есть версия, определенная в родительском проекте или в разделе ваших зависимостей). Если вы измените диапазон на точную версию или воспользуетесь одним из ключевых слов LATEST или RELEASE , Maven сможет определить номер версии (хотя имейте в виду, что эти ключевые слова несут свои риски.

Я бы рекомендовал определить в вашем родительском разделе раздел dependencyManagement с версиями, которые вы используете, тогда ваши проекты могут наследовать эти версии. Я недавно ответил на другой вопрос по этому поводу, выложу ссылку, если найду

0 голосов
/ 17 мая 2017

Начиная с версии 3.0.0, плагин maven-dependency-plugin теперь поддерживает это "из коробки". Авторы и благодарность Brian_Fox

0 голосов
/ 02 октября 2009

Проблема с диапазонами зависимостей заключается в том, что вы не указали одну из использованных вами версий. Если вы указали диапазон как [1.0.0,1.1.0-SNAPSHOT), тогда он может работать как вы ожидаете. Вы не можете предполагать, что 1.0 и 1.1 разрешат к 1.0. * И 1.1. *, Что вы, похоже, подразумеваете.

...