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.
---------------------------------------------------------------------
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
--
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
