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<bri...@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-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
