You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by ji...@gmail.com on 2009/07/20 22:30:07 UTC
build.plugins.plugin.dependencies nonsense
Greetings,
[INFO] [enforcer:display-info {execution: default}]
[INFO] Maven Version: 2.2.0
[INFO] JDK Version: 1.5.0_16 normalized as: 1.5.0-16
[INFO] OS Info: Arch: i386 Family: unix Name: linux Version: 2.6.29.5
It seems ridiculous to me that I have to specifically list a
dependency version when it is bound to a particular plugin. Please see
the example:
<build>
<plugins>
<plugin>
<artifactId>maven-remote-resources-plugin</artifactId>
<dependencies>
<dependency>
<groupId>com.mycom.super.resources</groupId>
<artifactId>checkstyle</artifactId>
<version>0.0.1-SNAPSHOT</version>
</dependency>
</dependencies>
<executions>
[...]
</executions>
</plugin>
</plugins>
When I already have defined a managed version of that dependency as such:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>com.mycom.super.resources</groupId>
<artifactId>checkstyle</artifactId>
<version>0.0.1-SNAPSHOT</version>
</dependency>
</dependencies>
</dependencyManagement>
When I don't code a version inside the <build> section, I receive the following:
[ERROR] FATAL ERROR
[INFO] ------------------------------------------------------------------------
[INFO] An invalid artifact was detected.
This artifact might be in your project's POM, or it might have been
included transitively during the resolution process. Here is the
information we do have for this artifact:
o GroupID: com.mycom.super.resources
o ArtifactID: checkstyle
o Version: <<< MISSING >>>
o Type: jar
[INFO] ------------------------------------------------------------------------
[INFO] Trace
org.apache.maven.artifact.InvalidArtifactRTException: For artifact
{com.mycom.super.resources:checkstyle:null:jar}: The version cannot be
empty.
at org.apache.maven.artifact.DefaultArtifact.validateIdentity(DefaultArtifact.java:147)
at org.apache.maven.artifact.DefaultArtifact.<init>(DefaultArtifact.java:122)
at org.apache.maven.artifact.factory.DefaultArtifactFactory.createArtifact(DefaultArtifactFactory.java:158)
at org.apache.maven.artifact.factory.DefaultArtifactFactory.createDependencyArtifact(DefaultArtifactFactory.java:70)
at org.apache.maven.project.artifact.MavenMetadataSource.createArtifacts(MavenMetadataSource.java:439)
at org.apache.maven.plugin.DefaultPluginManager.addPlugin(DefaultPluginManager.java:377)
at org.apache.maven.plugin.DefaultPluginManager.verifyVersionedPlugin(DefaultPluginManager.java:217)
at org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPluginManager.java:177)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(DefaultLifecycleExecutor.java:1539)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.getMojoDescriptor(DefaultLifecycleExecutor.java:1744)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.segmentTaskListByAggregationNeeds(DefaultLifecycleExecutor.java:446)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:176)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:41)
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:585)
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] ------------------------------------------------------------------------
Ugggh! Why must I duplicate this information? Worst of all, the
m-release-p doesn't bump these versions as I would hope it would. So,
these things quickly become out of sync and are a royal PITA to
maintain.
Please help!
-jesse
--
There are 10 types of people in this world, those
that can read binary and those that can not.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: build.plugins.plugin.dependencies nonsense
Posted by ji...@gmail.com.
Thank you for responding,
Using a property mitigates the issue, but only slightly. It seems
rather silly that I have declared a specific version within
<dependencyManagement> just to have it ignored when listing a specific
<dependency> of a specific <plugin>. I realize that project building
is different than a plugin's classpath, however, I've gone out of my
way to list GAV coordinates within dependencyManagement -- it doesn't
seem to be a punishment fitting of the crime to require that I also
set a version when one is already available in another section, albeit
somewhat philosophically unrelated.
The main goal here is that I want to unpack a m-remote-resource-p
created bundle and use the output within a plugin. I do not want to
have this dependency otherwise placed into any generated artifacts for
that module, e.g. the war. However, I need it to be available for the
plugin to operate properly. Perhaps I've misunderstood one of the
dependency scopes that would allow this behavior... I dunno. Either
way, it feels wrong that Maven requires me to code this information...
ugh.
-jesse
On Tue, Jul 21, 2009 at 8:02 AM, Brian Fox<br...@infinity.nu> wrote:
> Use a property instead.
>
> The plugin dependencies don't pick up a version from the depMgt
> because depMgt is about building your project and your classpaths, the
> plugin dependencies are about overriding a plugin's classpath...two
> very distinct things.
>
--
There are 10 types of people in this world, those
that can read binary and those that can not.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: build.plugins.plugin.dependencies nonsense
Posted by Brian Fox <br...@infinity.nu>.
Use a property instead.
The plugin dependencies don't pick up a version from the depMgt
because depMgt is about building your project and your classpaths, the
plugin dependencies are about overriding a plugin's classpath...two
very distinct things.
2009/7/20 jieryn <ji...@gmail.com>:
> Greetings,
>
> [INFO] [enforcer:display-info {execution: default}]
> [INFO] Maven Version: 2.2.0
> [INFO] JDK Version: 1.5.0_16 normalized as: 1.5.0-16
> [INFO] OS Info: Arch: i386 Family: unix Name: linux Version: 2.6.29.5
>
> It seems ridiculous to me that I have to specifically list a
> dependency version when it is bound to a particular plugin. Please see
> the example:
>
> <build>
> <plugins>
> <plugin>
> <artifactId>maven-remote-resources-plugin</artifactId>
> <dependencies>
> <dependency>
> <groupId>com.mycom.super.resources</groupId>
> <artifactId>checkstyle</artifactId>
> <version>0.0.1-SNAPSHOT</version>
> </dependency>
> </dependencies>
> <executions>
> [...]
> </executions>
> </plugin>
> </plugins>
>
> When I already have defined a managed version of that dependency as such:
>
> <dependencyManagement>
> <dependencies>
> <dependency>
> <groupId>com.mycom.super.resources</groupId>
> <artifactId>checkstyle</artifactId>
> <version>0.0.1-SNAPSHOT</version>
> </dependency>
> </dependencies>
> </dependencyManagement>
>
> When I don't code a version inside the <build> section, I receive the following:
>
> [ERROR] FATAL ERROR
> [INFO] ------------------------------------------------------------------------
> [INFO] An invalid artifact was detected.
>
> This artifact might be in your project's POM, or it might have been
> included transitively during the resolution process. Here is the
> information we do have for this artifact:
>
> o GroupID: com.mycom.super.resources
> o ArtifactID: checkstyle
> o Version: <<< MISSING >>>
> o Type: jar
>
> [INFO] ------------------------------------------------------------------------
> [INFO] Trace
> org.apache.maven.artifact.InvalidArtifactRTException: For artifact
> {com.mycom.super.resources:checkstyle:null:jar}: The version cannot be
> empty.
> at org.apache.maven.artifact.DefaultArtifact.validateIdentity(DefaultArtifact.java:147)
> at org.apache.maven.artifact.DefaultArtifact.<init>(DefaultArtifact.java:122)
> at org.apache.maven.artifact.factory.DefaultArtifactFactory.createArtifact(DefaultArtifactFactory.java:158)
> at org.apache.maven.artifact.factory.DefaultArtifactFactory.createDependencyArtifact(DefaultArtifactFactory.java:70)
> at org.apache.maven.project.artifact.MavenMetadataSource.createArtifacts(MavenMetadataSource.java:439)
> at org.apache.maven.plugin.DefaultPluginManager.addPlugin(DefaultPluginManager.java:377)
> at org.apache.maven.plugin.DefaultPluginManager.verifyVersionedPlugin(DefaultPluginManager.java:217)
> at org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPluginManager.java:177)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(DefaultLifecycleExecutor.java:1539)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.getMojoDescriptor(DefaultLifecycleExecutor.java:1744)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.segmentTaskListByAggregationNeeds(DefaultLifecycleExecutor.java:446)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:176)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
> at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:41)
> 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:585)
> 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] ------------------------------------------------------------------------
>
> Ugggh! Why must I duplicate this information? Worst of all, the
> m-release-p doesn't bump these versions as I would hope it would. So,
> these things quickly become out of sync and are a royal PITA to
> maintain.
>
> Please help!
> -jesse
>
> --
> There are 10 types of people in this world, those
> that can read binary and those that can not.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org