I have described innumerable times how aggregator POMs fix many problems
and this is one of them.
I exclude dependencies in the aggregated library and the module POMs
never have to worry about this.
This saves a lot of grief in our case where we have about 60 deliverable
modules that make up the application.
The 10 or so aggregation POMs deal with all the exclusions so the 60
projects do not worry about this issue.
The exclusions are very stable once you figure out what you want and
where you want to provide it.
After you set up your aggregations, you are done until you change your mind.
The individual developers do not have to worry about choice of version
or providing it at runtime.
The Maven dependency graph and hierarchy are very useful while setting
this up but after that, the developers do not have to reference this.
We probably use close to 75 third party libraries so this was a big
issue for us.
It also makes it easier to ensure that all the localhosts, test servers
and production servers are all running the same set of libraries.
Ron
On 17/01/2011 8:12 AM, Stevo Slavić wrote:
I wouldn't recommended using provided scope as you or your fellow
developers may unintentionally in development/compile time make use of
some resource or type from dependency in provided scope, but then get
a nasty surprise at runtime.
Typically I'd use dependencyManagement at parent level, and exclude
unwanted dependency as many times as needed. If that dependency set
with exclusions repeats across several different projects, then define
it once in a module with pom packaging, which gets imported (import
scope) in different projects.
Regards,
Stevo.
On Mon, Jan 17, 2011 at 1:59 PM, Jesse Farinacci<[email protected]> wrote:
Hi,
On Mon, Jan 17, 2011 at 4:49 AM,<[email protected]> wrote:
is it possible to exclude a dependency without specifying from which other
dependency it might come from ?
Like "wherever depA is coming from, exclude it" ?
Until MNG-1977 is resolved, you can perform a simple work around. E.g.
<project>
<build>
<dependencies>
<groupId>commons-logging</<groupId>
<artifactId>commons-logging</<artifactId>
<scope>provided</scope>
</dependencies>
</build>
</project>
The scope=provided instructs Maven to not actually bring that
dependency into the classpath, thus, it behaves as a global exclude.
-Jesse
--
There are 10 types of people in this world, those
that can read binary and those that can not.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
