Использует ли плагин Maven-dependency какое-либо другое разрешение артефактов, чем остальная часть maven?
Если я использую плагин Maven-dependency-plugin, то я не могу использовать диапазон версий. Также кажется, что версия определенного артефакта не обновляется, хотя более новая версия находится в удаленном репозитории.
почему это так?
использует Maven-dependency-plugin какой-то другой механизм, чем остальная часть maven для разрешения зависимостей? И если это так, то почему?
вот пример:
Я создал проект org.пример:орг.образец.простой.project1: jar и поместите его в репозиторий, используя версии 1.0.0-снимок, 1.0.0, 1.0.1 и 1.1.0-снимок
теперь я настроил плагин зависимостей следующим образом:
<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>
Если разрешение зависимостей будет таким же, как и в других зависимостях, версия shoud resolve (по крайней мере, на мой взгляд) в 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 ответов
Ok вот реальный ответ (я написал плагин зависимостей):
цели распаковки и копирования должны реплицировать некоторый основной код разрешения. К сожалению, этот код разрешения не был действительно в полезной форме api-wise. Из-за этого эти цели не обрабатывают диапазоны версий, а также не разрешают артефакты непосредственно из реактора (я, честно говоря, просто никогда не реализовывал их, потому что он сломал слишком много существующих вариантов использования, да, основной код разрешения был таким плохо)
гораздо лучшим подходом является использование форм xxx-зависимостей этих целей. Эти цели просят Maven сделать разрешение, прежде чем они будут вызваны, и поэтому оно на 100% совместимо. Вы можете использовать фильтры, такие как groupId и artifactId фильтр, чтобы эффективно получить список артефактов, которые вы хотите, и конечный результат будет таким же.
копия и распаковка определенно более гибкие и предназначались для гораздо более простого случая использования, который у меня был в то время. Я знаю то, что знаю. теперь я, вероятно, реализовал бы его больше как формы xxx-зависимостей для начала.
все, что сказано в Maven 3, код разрешения, наконец, полностью развязан...плагин зависимостей управляет большинством случаев использования, необходимых для этого. Я начну работать над новой версией плагина, чтобы полностью использовать только это...и хотя для этого потребуется maven 3, он, наконец, будет работать на 100% со всеми целями.
плагин зависимостей использует тот же механизм разрешения как и все остальное. Возможно, ваши репозитории не обновляют метаданные, потому что установлено значение никогда или еженедельно или что-то в этом роде. Вы можете заставить Maven обновить все метаданные удаленного репозитория, запустив a-U.
плагин зависимостей также не перезаписывает загруженные зависимости по умолчанию, если они уже существуют в цели. Вы можете сделать чистую или настроить цель заставить переписывать. Есть три параметра, вы можете установить в true: overWriteIfNewer, overWriteReleases и overWriteSnapshots. См.документация для получения более подробной информации.
Edit: на основе вашего обновленного вопроса проблема заключается в том, что вы используете диапазон зависимостей. Диапазоны в порядке, если есть что-то для разрешения версии (например, у вас есть версия, определенная в Родительском проекте или в вашем раздел dependencies). Если вы измените диапазон на точную версию или используете один из последние или выпуск ключевые слова, Maven сможет разрешить номер версии (хотя имейте в виду, что эти ключевые слова несут свои собственные риски.
Я бы рекомендовал определить раздел dependencyManagement в вашем Родителе с используемыми версиями, тогда ваши проекты могут наследовать эти версии. Я ответил на другой вопрос об этом недавно, я опубликую ссылку, если найду ее
проблема с диапазонами зависимостей заключается в том, что вы не указали одну из используемых версий. Если вы указали диапазон как [1.0.0, 1.1.0-SNAPSHOT), то он может сделать так, как вы ожидаете. Вы не можете предположить, что 1.0 и 1.1 разрешатся до 1.0.* и 1.1. именно это вы, кажется, подразумеваете.
начиная с версии 3.0.0 плагин Maven-dependency теперь поддерживает это из коробки. Кредиты и спасибо Brian_Fox