Re: Maven - offer anything for runtime?
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: H... 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
Re: Maven - offer anything for runtime?
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
Re: Maven - offer anything for runtime?
H... 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
Re: Maven - offer anything for runtime?
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
Re: Maven - offer anything for runtime?
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
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-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven - offer anything for runtime?
On Fri, Apr 27, 2012 at 11:40 AM, J.V. jvsr...@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-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
Re: Maven - offer anything for runtime?
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-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
Re: Maven - offer anything for runtime?
On Fri, Apr 27, 2012 at 8:40 AM, J.V. jvsr...@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-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
Re: Maven - offer anything for runtime?
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-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven - offer anything for runtime?
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.jvsr...@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-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
Re: Maven - offer anything for runtime?
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.jvsr...@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-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
Re: Maven - offer anything for runtime?
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
Re: Maven - offer anything for runtime?
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
Re: Maven - offer anything for runtime?
On 27 April 2012 12:19, J.V. jvsr...@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-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven - offer anything for runtime?
On 27 April 2012 12:27, J.V. jvsr...@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-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven - offer anything for runtime?
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
Re: Maven - offer anything for runtime?
On 27/04/2012 3:37 PM, Hilco Wijbenga wrote: On 27 April 2012 12:19, J.V.jvsr...@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-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
Re: Maven - offer anything for runtime?
On 27 April 2012 12:47, Ron Wheeler rwhee...@artifact-software.com wrote: On 27/04/2012 3:37 PM, Hilco Wijbenga wrote: On 27 April 2012 12:19, J.V.jvsr...@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-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven - offer anything for runtime?
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-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven - offer anything for runtime?
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-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
Re: Maven - offer anything for runtime?
On 4/27/2012 1:37 PM, Hilco Wijbenga wrote: On 27 April 2012 12:19, J.V.jvsr...@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-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
Re: Maven - offer anything for runtime?
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-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
Re: Maven - offer anything for runtime?
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-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
