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 <[email protected]> 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 <[email protected]>
> 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
>> <[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]
>>
>
> ---------------------------------------------------------------------
> 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]

Reply via email to