如果我使用 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] ------------------------------------------------------------------------

最佳答案

好的，这是真正的答案(我写了依赖插件):

解包和复制目标必须复制一些核心解析代码。不幸的是，解析代码并不是真正以 API 方式可用的形式。正因为如此，这些目标不处理版本范围，也不直接从 react 器中解析工件(坦率地说，我只是从未实现过它们，因为它破坏了太多现有的用例，是的，解析代码是那么糟糕)

更好的方法是使用这些目标的 xxx-dependencies 形式。这些目标要求 Maven 在调用它们之前进行解析，因此它是 100% 兼容的。您可以使用 groupId 和 artifactId 过滤器等过滤器来有效地获取您想要的工件列表，最终结果将是相同的。

复制和解包肯定更灵活，并且是为我当时的一个更简单的用例而设计的。知道我现在所知道的，我可能会更喜欢从 xxx-dependencies 表单开始实现它。

话虽如此，在 Maven 3 中，解析代码终于完全解耦了……依赖插件驱动了大多数所需的用例。我将开始着手开发新版本的插件，以便尽快充分利用这一点……虽然它需要 maven 3，但它最终将 100% 实现所有目标。

关于java - maven-dependency-plugin 是否使用其他类型的工件解析而不是 maven 的其余部分？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1221758/