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.
=> exactly, so at runtime if one lib depends on log4j 16 and
another lib depends on log4j 12, then there will be problems if log4j
version 12 is deployed with the app because there are new methods in the
later release that are in use.
If only log4j 16 is chosen, there could be problems if two methods have
the same signature, but different functionality. We had an issue like
this (not with log4j), but two releases of a jar that claimed to be
backwards compatible had two methods with the same signature but
different functionality so things were blowing up in our SaaS
enviornment in areas that had not changed (our code), but a dependency
was upgraded.
So at runtime you really need all transitive dependencies and for the
right ones to be in the classpath at the right time on execution.
J.V.
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.
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
