Whether or not it is what I *was* looking at, it certainly seems apropos :-)
On Sun, Apr 29, 2012 at 10:50 PM, Wayne Fay <wayne...@gmail.com> wrote: > Hmmmm... are you talking about PomStrap? ;-) > > http://pomstrap.jfluid.com/ [site is down for me right now] > http://www.pomstrap.techlab.smk.fr/en/ > http://pomstrap.tigris.org/ > > PomStrap is a hierarchical Class-Loader based on the Maven's artifact > repository model. In a nutshell, it provides a runtime feature to > Maven. > > Wayne > > On 4/29/12, Benson Margulies <bimargul...@gmail.com> wrote: >> 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 >> >> > > --------------------------------------------------------------------- > 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
