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 <[email protected]> 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 >>>>> trouble. >>>>> 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: [email protected] > skype: ronaldmwheeler > phone: 866-970-2435, ext 102 > > > --------------------------------------------------------------------- > 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]
