Java maven依赖插件是否比maven的其他插件使用了其他类型的工件解析？

如果我使用maven依赖插件，那么我就不能使用版本范围。此外，尽管远程存储库中有一个较新的版本，但是在那里定义的工件的版本似乎没有得到更新

为什么会这样

使用maven依赖插件来解决依赖关系，而不是使用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>

---

依赖插件与其他插件使用相同的解析机制。您的存储库可能没有更新元数据，因为设置为“从不”、“每周”或其他。您可以通过使用-U命令来强制Maven刷新所有远程存储库元数据

如果下载的依赖项已经存在于目标中，则依赖项插件默认情况下也不会覆盖这些依赖项。您可以执行清理或将目标配置为强制覆盖。有三个参数可以设置为true：overWriteIfNewer、overWriteReleases和overWriteSnapshots。有关更多详细信息，请参阅

编辑：根据您更新的问题，问题在于您使用的是依赖范围。只要存在要解析版本的内容（例如，在父项目或依赖项部分中定义了版本），范围就可以。如果您将范围更改为精确的版本，或者使用其中一个，Maven将能够解析版本号（不过请注意，这些关键字也有其自身的风险）

---

我建议用您使用的版本在您的父级中定义dependencyManagement部分，然后您的项目可以继承这些版本。最近我回答了另一个有关此问题的问题，如果我发现它，我将发布一个链接。

依赖范围的问题是您没有指定所使用的版本之一。如果您指定了range作为[1.0.0,1.1.0-SNAPSHOT]，它可能会按照您的预期运行。您不能假设1.0和1.1将解析为1.0.*和1.1.*这似乎就是您的意思。

好的，这是真正的答案（我编写了依赖插件）：

解包和复制目标必须复制一些核心解析代码。不幸的是，解析代码的api形式不可用。因此，这些目标不能处理版本范围，也不能直接从反应堆解析工件（坦白说，我从来没有实现过它们，因为它破坏了太多现有的用例，是的，核心解析代码就那么糟糕）

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

拷贝和解包显然更加灵活，并且是为了我当时拥有的一个简单得多的用例而设计的。知道我现在知道的，我可能会更像从xxx依赖项表单开始实现它

---

综上所述，在Maven 3中，解析代码最终是完全解耦的…依赖插件驱动了这方面所需的大多数用例。我将很快开始开发插件的新版本，以充分利用这一点…虽然它需要Maven 3，但它最终将100%实现所有目标。

从3.0.0版开始maven依赖插件现在支持这种开箱即用。

---

感谢Brian_Fox

我用一个示例更新了我的问题。所讨论的项目总是以-U作为参数调用。在给定的示例中，配置已设置为true（可能我还需要添加其他overwrite*选项。这里有一种方法可以定义父项目中的依赖项：依赖项范围确实存在问题。请参见上面的答案。答案是我从未实现过此目标的范围。哈！我知道！这解释得很清楚。我将看一看maven 3，但我不是。）我不是很有希望，因为我的版本不适用于除2.0.10之外的任何maven版本（兼容性承诺如此之多）。什么是xxx依赖项表单？？建议的解决方法将导致使用此pom的其他项目将zip文件检索为可传递依赖项。@BrianFox“这些目标的xxx依赖项表单”是什么意思？它对我不起作用。我有

org.apache.maven.plugins maven依赖插件3.0.2

，版本

[x.y.z，）

[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] ------------------------------------------------------------------------