如果我使用maven-dependency-plugin插件,我不能使用版本范围.此外,似乎有一个定义的工件的版本没有得到更新,虽然较新的版本是在远程存储库中.
为什么？
使用maven-dependency-plugin一些其他机制来解决依赖关系？如果是这样,为什么？
这里有一个例子：
我已经创建了一个项目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] ------------------------------------------------------------------------
解决方法
好的,这是真正的答案(我写了依赖插件)：
解压缩和复制目标必须复制一些核心解决方案代码.不幸的是,解决方案的代码并不是真的有用的形式.因此,这些目标不能处理版本范围,也不会直接从反应堆中解析工件(我坦率地说,从来没有实现它们,因为它破坏了现有的大量使用案例,核心解决方案代码是坏的)
一个更好的方法是使用这些目标的xxx依赖形式.这些目标要求Maven在被调用之前做出决议,所以它是100％兼容的.您可以使用像groupId和artifactId过滤器这样的过滤器来有效地获取所需的工件列表,并且最终结果将是一样的.
复制和解压缩肯定更灵活,旨在为当时使用的一个更简单的用例.知道我现在知道的,我可能会实现它更像是xxx依赖关系形式开始.
所有这一切,在Maven 3中,解决方案代码终于完全解耦了…依赖插件驱动了大部分需要的用例.我将开始使用新版本的插件,以便尽快充分利用此功能,而且它将需要maven 3,最终将全部达到100％的目标.
