maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Narrell <>
Subject Re: Maven - offer anything for runtime?
Date Sat, 28 Apr 2012 19:58:57 GMT
You can also use the maven-enforcer-plugin to identify dependencies
that attempt to bring in older versions of transitive dependencies.

On Apr 28, 2012, at 10:55 AM, Ron Wheeler
<> wrote:

> It is not that hard.
> You just paste the same exclusion into each POM that includes something that brings in
a version that you do not want.
> To reduce the effort, make your POMs that produce artifacts that you deploy depend on
your own POMs that only serve to bring in third party tools.
> In that way the developer does not have to do any exclusions since your library POMs
have already setup the third party dependencies correctly.
> mywar.pom depends on myapache.pom and myspring.pom and myjasper.pom.
> myapache.pom and myspring.pom and myjasper.pom are sanitized to get rid of  transitive
dependencies that I will provide at run-time.
> Makes the job very simple
> Once you do it once the developers have a much simpler life.
> Ron
> On 27/04/2012 5:47 PM, J.V. wrote:
>> If I have a log4j exclusion in every <dependency> section, that would look
quite messy.  Is there a way to globally do this?
>> We have dozens of dependencies, just looks like there would be an easier way.  Nearly
everything depends on log4j so that is a lot of work to add to every dependency.  Not sure
there is an easier way though.
>> J.V.
>> On 4/27/2012 1:44 PM, Ron Wheeler wrote:
>>> You can either be god-like or trust that Tomcat will be.
>>> You only need to do it once.
>>> It takes a bit of time but, at the end, you know what you are running in production
and developers don't have to worry about getting a MethodNotFound at run-time.
>>> It is not as bad as you think if you have a good IDE with Maven support. We use
Eclipse STS from Springframework.
>>> It will look through your project POM and tell you where all your dependencies
are coming from.
>>> You can then write excludes on your dependencies to stop them from bringing in
transitive dependencies that you do not want.
>>> We made our own poms to bring in all the Apache stuff (commons-xxx, log4j, etc.)
so we had a single dependency that developers could use in their projects to get the "right"
version of all the "right" Apache libraries. They never had to worry about them again and
if we wanted to upgrade log4j, we just did it in one place.
>>> For third party libraries that had transitive dependencies on something like
log4j, we just added an exclude to their dependency specification.
>>> We had a small team with a lot of modules so it really made everyone's life easier
and I did not have to worry that someone would inject an old version into the system.
>>> Ron
>>> On 27/04/2012 3:27 PM, J.V. wrote:
>>>> On 4/27/2012 10:04 AM, Ron Wheeler wrote:
>>>>> On 27/04/2012 11:40 AM, J.V. wrote:
>>>>>> I understand how Maven resolves dependencies (and transitive dependencies)
at compile time, but does it bring anything to the table at run time?
>>>>> It makes your artifacts that your run-time environment will execute.
>>>>> It is a build tool.
>>>>>> For example, if I have in my application dependency list two versions
of log4J (let's say version 8 and version 15), will I deploy both jars/version along with
my app on say a tomcat server inside the war?
>>>>> Fix it so you only have 1.
>>>>> Settle on the "right" versions of third party libraries and use "exclusions"
in your dependencies to prevent other libraries from grabbing older versions.
>>>>    => this is a very tedious task.  I have to be godlike to know the transitive
dependencies and what libraries they use, and inspect my local repository, find out all dups
of everything, find out which top level dependency needs it and go exclude this.  This is
a maintenance nightmare.
>>>>> Most software is upwards compatible so you will very seldom have any
>>>>> For log4j, you want to specify the latest version.
>>>>>> At runtime which one does it choose?  If I am executing the code
that depends on version 8, how would the correct jar be in the classpath at that point and
later log4J version 15 be in my classpath when code that has that dependency executes?
>>>>> The runtime behaviour depends on the environment (Tomcat).
>>>>> If you have 2 possible versions available, it will pick one based on
how the programmers who wrote the environment thought that the world should work and in Tomcats
case, what order the webapps started when the server came up which is not in your control.
>>>>> This can lead to MethodNotFound exceptions at runtime where someone calls
a method that is available in Version 15 but your environment picked 8 to load.
>>>>> Don't give it the choice.
>>>>>> At runtime, Maven is out of the picture correct?  This is a missing
piece for me.
>>>>> Yes. It just builds the wars, jars, etc. as per your specifications.
>>>>>> thanks
>>>>>> J.V.
> --
> Ron Wheeler
> President
> Artifact Software Inc
> email:
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message