I can't track down the thing I was referring to. It has a cute project name and was embedded maven as a way to manage classpath containers and plugin downloads at runtime. I also looked a bit at SISU to see if it was applicable to your problem, but the eclipse site is not revealing at this time.
On Sat, Apr 28, 2012 at 3:58 PM, Matt Narrell <matt.narr...@gmail.com> wrote: > 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 > <rwhee...@artifact-software.com> 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: rwhee...@artifact-software.com >> skype: ronaldmwheeler >> phone: 866-970-2435, ext 102 >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
