Have you checked the possibility of using the enforcer plugin for your
use case?

This does something close:
http://maven.apache.org/enforcer/enforcer-rules/bannedDependencies.html

or you could try creating a custom rule:

http://maven.apache.org/enforcer/enforcer-api/writing-a-custom-rule.html

Adam



On Tue, 2009-12-01 at 03:09 -0800, Bryan Loofbourrow wrote:
> I'm hoping for advice about the best way to accomplish something in
> Maven. I am willing to write a plugin if that's the right answer.
> 
>  
> 
> Here's the thing I want to accomplish:
> 
>  
> 
> Given a Maven project that builds an ear/war, and which contains a
> dependencyManagement section, generally inherited from its parent or a
> more distant ancestor, fail the Maven build if any version chosen for
> inclusion in the reactor (or the ear or war, if you want to look at it
> that way) does not match the version declared in the
> dependencyManagement section.
> 
>  
> 
> The point being, of course, to catch those cases where Maven's version
> choices override the ones I made in dependencyManagement, and fail fast.
> 
> 
>  
> 
> So, is there a way to do it now? If not, what would be the best practice
> for accomplishing it? Write a plugin that executes as part of the ear
> build? Write a plugin that executes as part of some separate analysis
> project, and which uses the ear artifact as a dependency or parameter?
> 
>  
> 
> I will confess that there's part of me that thinks that this whole need
> should not arise, that Maven should simply decline to add anything to
> the reactor that matches something declared in dependencyManagement in
> every way except for a mismatching version. That's a separate
> discussion. If anyone knows whether 3.0 operates more like that, I'd be
> interested to know it.
> 
>  
> 
> Thanks,
> 
>  
> 
> -- Bryan
> 
>  
> 
> Bryan Loofbourrow
> 
> Principal Software Engineer
> 
> Amdocs Interactive
> 
> o:+1.206.830.7724 | m: +1.707.849.8892 |
> 
> [email protected] <mailto:[email protected]> 
> 
> 
> 
> This message and the information contained herein is proprietary and 
> confidential and subject to the Amdocs policy statement,
> you may review at http://www.amdocs.com/email_disclaimer.asp


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to