You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by "J.V." <jv...@gmail.com> on 2012/04/27 17:40:06 UTC
Maven - offer anything for runtime?
I understand how Maven resolves dependencies (and transitive
dependencies) at compile time, but does it bring anything to the table
at run time?
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?
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?
At runtime, Maven is out of the picture correct? This is a missing
piece for me.
thanks
J.V.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven - offer anything for runtime?
Posted by "J.V." <jv...@gmail.com>.
Do you remember the blog post or have other resources that would point
to how to control the runtime classpath?
thanks
J.V.
On 4/27/2012 9:53 AM, Benson Margulies wrote:
> On Fri, Apr 27, 2012 at 11:40 AM, J.V.<jv...@gmail.com> wrote:
>> I understand how Maven resolves dependencies (and transitive dependencies)
>> at compile time, but does it bring anything to the table at run time?
>>
>> 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?
>>
>> 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?
>>
>> At runtime, Maven is out of the picture correct? This is a missing piece
>> for me.
> There was a blog post some time back about incorporating Maven as a
> runtime classpath manager, I don't think it went in this direction.
> You are looking, I think, for OSGi. It is true that 'classworlds', the
> internal structure in Maven that allows different plugins to have
> different versions of different things in their classpaths, is an open
> source component that you could apply, but nothing in Maven will help
> you set that up unless you want to structure all your code as maven
> plugins.
>
>
>> thanks
>>
>> J.V.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven - offer anything for runtime?
Posted by Benson Margulies <bi...@gmail.com>.
On Fri, Apr 27, 2012 at 11:40 AM, J.V. <jv...@gmail.com> wrote:
> I understand how Maven resolves dependencies (and transitive dependencies)
> at compile time, but does it bring anything to the table at run time?
>
> 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?
>
> 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?
>
> At runtime, Maven is out of the picture correct? This is a missing piece
> for me.
There was a blog post some time back about incorporating Maven as a
runtime classpath manager, I don't think it went in this direction.
You are looking, I think, for OSGi. It is true that 'classworlds', the
internal structure in Maven that allows different plugins to have
different versions of different things in their classpaths, is an open
source component that you could apply, but nothing in Maven will help
you set that up unless you want to structure all your code as maven
plugins.
>
> thanks
>
> J.V.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven - offer anything for runtime?
Posted by Hilco Wijbenga <hi...@gmail.com>.
On 27 April 2012 12:47, Ron Wheeler <rw...@artifact-software.com> wrote:
> On 27/04/2012 3:37 PM, Hilco Wijbenga wrote:
>>
>> On 27 April 2012 12:19, J.V.<jv...@gmail.com> wrote:
>>>
>>> this is the issue (that only one artifact is picked). How does it know
>>> to
>>> pick the right one?
>>>
>>> What if log4j ver 1.2.15 has a method that log4j 1.2.10 does not have?
>>
>> You use 1.2.15.
>>
>>> also what if both jars have a method with the same signature but function
>>> differently?
>>
>> You upgrade or downgrade something else until everything works with
>> the same version of log4j.
>
>
> Or you use another library. Upward compatibility is a sign of a well-run
> utility project.
> If their new version breaks code that uses the older version without error,
> that is a warning that their QC process is not under control or they just
> don't care.
Well, I was going to suggest that too but I figured just mentioning
upgrading/downgrading would be less controversial. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven - offer anything for runtime?
Posted by Ron Wheeler <rw...@artifact-software.com>.
On 27/04/2012 3:37 PM, Hilco Wijbenga wrote:
> On 27 April 2012 12:19, J.V.<jv...@gmail.com> wrote:
>> this is the issue (that only one artifact is picked). How does it know to
>> pick the right one?
>>
>> What if log4j ver 1.2.15 has a method that log4j 1.2.10 does not have?
> You use 1.2.15.
>
>> also what if both jars have a method with the same signature but function
>> differently?
> You upgrade or downgrade something else until everything works with
> the same version of log4j.
Or you use another library. Upward compatibility is a sign of a well-run
utility project.
If their new version breaks code that uses the older version without
error, that is a warning that their QC process is not under control or
they just don't care.
>
>> In this case you need both jars and at runtime to have the right jar in the
>> classpath for that piece of code.
> You can't have multiple versions of the same JAR on the classpath and
> expect things to work. At best, only the first one found is used and
> the others are ignored but usually your app develops all kinds of
> interesting features. :-)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven - offer anything for runtime?
Posted by "J.V." <jv...@gmail.com>.
On 4/27/2012 1:37 PM, Hilco Wijbenga wrote:
> On 27 April 2012 12:19, J.V.<jv...@gmail.com> wrote:
>> this is the issue (that only one artifact is picked). How does it know to
>> pick the right one?
>>
>> What if log4j ver 1.2.15 has a method that log4j 1.2.10 does not have?
> You use 1.2.15.
>
>> also what if both jars have a method with the same signature but function
>> differently?
> You upgrade or downgrade something else until everything works with
> the same version of log4j.
can't do this. one version will break something if the method
signatures are the same yet have different functionality.
I think the answer from this thread to switch a new version of jar
in/out at run time to get the right version is OSGi.
>
>> In this case you need both jars and at runtime to have the right jar in the
>> classpath for that piece of code.
> You can't have multiple versions of the same JAR on the classpath and
> expect things to work. At best, only the first one found is used and
> the others are ignored but usually your app develops all kinds of
> interesting features. :-)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
> .
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven - offer anything for runtime?
Posted by Hilco Wijbenga <hi...@gmail.com>.
On 27 April 2012 12:19, J.V. <jv...@gmail.com> wrote:
> this is the issue (that only one artifact is picked). How does it know to
> pick the right one?
>
> What if log4j ver 1.2.15 has a method that log4j 1.2.10 does not have?
You use 1.2.15.
> also what if both jars have a method with the same signature but function
> differently?
You upgrade or downgrade something else until everything works with
the same version of log4j.
> In this case you need both jars and at runtime to have the right jar in the
> classpath for that piece of code.
You can't have multiple versions of the same JAR on the classpath and
expect things to work. At best, only the first one found is used and
the others are ignored but usually your app develops all kinds of
interesting features. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven - offer anything for runtime?
Posted by "J.V." <jv...@gmail.com>.
On 4/27/2012 3:26 PM, Manfred Moser wrote:
> On Fri, April 27, 2012 12:19 pm, J.V. wrote:
>> this is the issue (that only one artifact is picked). How does it know
>> to pick the right one?
>>
>> What if log4j ver 1.2.15 has a method that log4j 1.2.10 does not have?
>>
>> also what if both jars have a method with the same signature but
>> function differently?
>>
>> In this case you need both jars and at runtime to have the right jar in
>> the classpath for that piece of code.
> That is not how the classpath works... if you have the same method with
> identical signature in the classpath whatever method is first in the class
> path will be picked. Depending on your classpath that could be either so
> just having both in there does not work.
yes, I know, this is the problem I am trying to solve. I believe OSGi
has been the answer to the response on how to have multiple versions of
the same jar and switch at runtime as needed.
>
> manfred
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven - offer anything for runtime?
Posted by Manfred Moser <ma...@mosabuam.com>.
On Fri, April 27, 2012 12:19 pm, J.V. wrote:
> this is the issue (that only one artifact is picked). How does it know
> to pick the right one?
>
> What if log4j ver 1.2.15 has a method that log4j 1.2.10 does not have?
>
> also what if both jars have a method with the same signature but
> function differently?
>
> In this case you need both jars and at runtime to have the right jar in
> the classpath for that piece of code.
That is not how the classpath works... if you have the same method with
identical signature in the classpath whatever method is first in the class
path will be picked. Depending on your classpath that could be either so
just having both in there does not work.
manfred
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven - offer anything for runtime?
Posted by "J.V." <jv...@gmail.com>.
this is the issue (that only one artifact is picked). How does it know
to pick the right one?
What if log4j ver 1.2.15 has a method that log4j 1.2.10 does not have?
also what if both jars have a method with the same signature but
function differently?
In this case you need both jars and at runtime to have the right jar in
the classpath for that piece of code.
J.V.
On 4/27/2012 11:55 AM, Kalle Korhonen wrote:
> On Fri, Apr 27, 2012 at 8:40 AM, J.V.<jv...@gmail.com> wrote:
>> I understand how Maven resolves dependencies (and transitive dependencies)
>> at compile time, but does it bring anything to the table at run time?
>> 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?
>> 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?
> Surprised that nobody else mentioned this, but assuming your GA
> (Group, Artifact) coordinates stay the same, Maven would pick only
> *one* version of the same artifact to be included in your classpath,
> as a dependent lib for your WAR or whatever else it is you are
> building. Google on on "Maven nearest version resolution" to find out
> more. There's no need for exclusions (in that case).
>
> Kalle
>
>> At runtime, Maven is out of the picture correct? This is a missing piece
>> for me.
>>
>> thanks
>>
>> J.V.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven - offer anything for runtime?
Posted by Kalle Korhonen <ka...@gmail.com>.
On Fri, Apr 27, 2012 at 8:40 AM, J.V. <jv...@gmail.com> wrote:
> I understand how Maven resolves dependencies (and transitive dependencies)
> at compile time, but does it bring anything to the table at run time?
> 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?
> 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?
Surprised that nobody else mentioned this, but assuming your GA
(Group, Artifact) coordinates stay the same, Maven would pick only
*one* version of the same artifact to be included in your classpath,
as a dependent lib for your WAR or whatever else it is you are
building. Google on on "Maven nearest version resolution" to find out
more. There's no need for exclusions (in that case).
Kalle
>
> At runtime, Maven is out of the picture correct? This is a missing piece
> for me.
>
> thanks
>
> J.V.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven - offer anything for runtime?
Posted by "J.V." <jv...@gmail.com>.
At runtime, everyone everywhere needs multiple versions of the same jar
at runtime, but this may need may not be possible (maybe OSGi addresses
this).
If you start out with the basics like Spring/Hibernate, you will get two
versions of log4j downloaded as transitive dependencies.
It is not exactly safe to substitute one jar for the other or to expect
backwards compatibility. It would be ideal if this were the case, but
unfortunately cannot be controlled by the end user. It is unfortunate
that two method calls have the same signature in different releases but
have different functionality entirely, but it happens. There are some
projects that try harder at this and some that simply do not care.
The only thing you can say across the board is that at runtime, you
should have in the classpath the transitive dependencies of the line of
code that is being executed. I am not sure if this is entirely possible.
J.V.
On 4/27/2012 12:53 PM, Daniel Serodio wrote:
> For webapps, Maven is completely out of the picture at runtime. If
> you're running a (console) app from within the project folder - i.e.
> you have the pom.xml - you may use the Exec Maven Plugin:
>
> http://mojo.codehaus.org/exec-maven-plugin/java-mojo.html
>
> But in any case, you shouldn't have two different versions of a
> library (like log4j). I you really, really need two different versions
> of a library, the Shade plugin may help, as its able to rename a
> package so you can refer to these different versions separately.
>
> HTH,
> Daniel Serodio
>
> 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?
>>
>> 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?
>>
>> 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?
>>
>> At runtime, Maven is out of the picture correct? This is a missing
>> piece for me.
>>
>> thanks
>>
>> J.V.
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven - offer anything for runtime?
Posted by Daniel Serodio <ds...@mandic.com.br>.
For webapps, Maven is completely out of the picture at runtime. If
you're running a (console) app from within the project folder - i.e. you
have the pom.xml - you may use the Exec Maven Plugin:
http://mojo.codehaus.org/exec-maven-plugin/java-mojo.html
But in any case, you shouldn't have two different versions of a library
(like log4j). I you really, really need two different versions of a
library, the Shade plugin may help, as its able to rename a package so
you can refer to these different versions separately.
HTH,
Daniel Serodio
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?
>
> 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?
>
> 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?
>
> At runtime, Maven is out of the picture correct? This is a missing
> piece for me.
>
> thanks
>
> J.V.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven - offer anything for runtime?
Posted by "J.V." <jv...@gmail.com>.
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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven - offer anything for runtime?
Posted by Hilco Wijbenga <hi...@gmail.com>.
On 27 April 2012 12:27, J.V. <jv...@gmail.com> 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.
It's not nearly that bad. Firstly, it's rarely an issue and Maven
usually does the right thing. Secondly, Maven offers tools to see what
is used. Moreover, IDEs like Eclipse (with the Maven plugin) allow you
to see what JARs are included and why.
It's not nearly as onerous as you make it out to be. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven - offer anything for runtime?
Posted by Benson Margulies <bi...@gmail.com>.
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 <wa...@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 <bi...@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 <ma...@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
>>> <rw...@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: rwheeler@artifact-software.com
>>>> skype: ronaldmwheeler
>>>> phone: 866-970-2435, ext 102
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven - offer anything for runtime?
Posted by Wayne Fay <wa...@gmail.com>.
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 <bi...@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 <ma...@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
>> <rw...@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: rwheeler@artifact-software.com
>>> skype: ronaldmwheeler
>>> phone: 866-970-2435, ext 102
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven - offer anything for runtime?
Posted by Benson Margulies <bi...@gmail.com>.
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 <ma...@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
> <rw...@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: rwheeler@artifact-software.com
>> skype: ronaldmwheeler
>> phone: 866-970-2435, ext 102
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven - offer anything for runtime?
Posted by Matt Narrell <ma...@gmail.com>.
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
<rw...@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: rwheeler@artifact-software.com
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven - offer anything for runtime?
Posted by Ron Wheeler <rw...@artifact-software.com>.
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: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven - offer anything for runtime?
Posted by "J.V." <jv...@gmail.com>.
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.
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>
>>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven - offer anything for runtime?
Posted by Ron Wheeler <rw...@artifact-software.com>.
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-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven - offer anything for runtime?
Posted by "J.V." <jv...@gmail.com>.
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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven - offer anything for runtime?
Posted by Ron Wheeler <rw...@artifact-software.com>.
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.
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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org