You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Bryan Loofbourrow <br...@amdocs.com> on 2009/12/01 12:09:19 UTC
Automating dependencyManagement enforcement
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 |
bryanl@amdocs.com <ma...@amdocs.com>
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
RE: Automating dependencyManagement enforcement
Posted by Bryan Loofbourrow <br...@amdocs.com>.
>> Have you checked the possibility of using the enforcer plugin for
your use case?
It's a point. But really all that adds to this, that I can see, is the
ability to fail the build, which is already easy to from within a plugin
you're writing.
>> This does something close:
>>
http://maven.apache.org/enforcer/enforcer-rules/bannedDependencies.html
I don't see how to parameterize this with the dependencyManagement
values. But it does seem like a usefully rich source of code to examine.
>> Adam
Thanks,
-- Bryan
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 |
>
> bryanl@amdocs.com <ma...@amdocs.com>
>
>
>
> 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: 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
Re: Automating dependencyManagement enforcement
Posted by "Adam Leggett (UPCO)" <ad...@upco.co.uk>.
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 |
>
> bryanl@amdocs.com <ma...@amdocs.com>
>
>
>
> 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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Automating dependencyManagement enforcement
Posted by Bryan Loofbourrow <br...@amdocs.com>.
From: anders.g.hammar@gmail.com [mailto:anders.g.hammar@gmail.com] On
Behalf Of Anders Hammar
Sent: Tuesday, December 01, 2009 4:27 AM
To: Maven Users List
Subject: Re: Automating dependencyManagement enforcement
In Maven you can force a specific version to be used by adding square
brackets:
<version>[1.0]</version>
By doing so you'll make sure Maven doesn't override your version of
choice.
However, this will impact projects depending on your artifacts. Normally
the
version defined closest to the level you're building has preference, but
forcing a specific version will change that behavior. Also, if two
different
versions are forced the build will fail.
/Anders
That's almost there, isn't it? But you're right, it's too heavy handed
for what I want, which is more about maintaining control over
third-party artifact versions when I build a particular assembly that
packages them (war, ear, tgz, ...), than about forcing everyone who
uses the artifacts of mine that went into that assembly, to make their
own assemblies, to be required to insist on using those versions.
Thanks,
-- Bryan
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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Automating dependencyManagement enforcement
Posted by Anders Hammar <an...@hammar.net>.
In Maven you can force a specific version to be used by adding square
brackets:
<version>[1.0]</version>
By doing so you'll make sure Maven doesn't override your version of choice.
However, this will impact projects depending on your artifacts. Normally the
version defined closest to the level you're building has preference, but
forcing a specific version will change that behavior. Also, if two different
versions are forced the build will fail.
/Anders
On Tue, Dec 1, 2009 at 12:09, Bryan Loofbourrow <
bryan.loofbourrow@amdocs.com> 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 |
>
> bryanl@amdocs.com <ma...@amdocs.com>
>
>
>
> 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