Re: dependencies are bloated in M2
FWIW, I want to mention that we did end up using exclusions and that did the trick. What I was missing was how could I find what was dependent on what. For that the mvn site | Dependency Report provided the answer. From there it was a matter of excluding the dependencies I did not want. Painful but effective. So I was hoping that there would be a POM level exclusions element that would exclude the dependencies from all the artifacts in that POM. That would be useful. Thanks for the clarifications on the provided vs exclusion concept. Using Provided does seem a little hokey. Pankaj craigmcc wrote: On 2/6/07, Bashar Abdul Jawad [EMAIL PROTECTED] wrote: Yes, but sometimes you will need to use a dependency for compile time only, and NOT for runtime. You don't need the container to provide it for you either because it is not required for runtime. Example: aspectjtools.jar. You can't exclude it because your project will not compile. The only way is to give it the provided scope. That is not correct. Declaring a dependency to be optional puts it on the compile classpath, but avoids any attempt to include it at runtime. Even if your container doesn't provide it that's not a problem, maven doesn't care. I know it is not very clean to give a dependency a provided scope when it's not going to be provided anywhere, but sometimes you need to do this if you want to compile against it. The semantics of provided are different than optional even though Maven does not enforce it. The code you write against a provided API assumes that the API will indeed be provided by the container. As an example, you might declare as provided a library that you've installed in Tomcat's common/lib directory. The library must be there in order for the application to function -- but Maven can assume that it will indeed by supplied by the container, so won't include it in the WAR. Optional, on the other hand, means what it says. Declaring such a dependency means that you will need it available at compile time FOR THE DEPENDENCY, but not necessarily for your own code (unless you explicitly need it for other reasons). The library is explicitly NOT required at runtime, because your dependency has said, in effect, I can use this library if it exists, but if it does not, no harm no foul. Note also that optional is NOT a scope -- it is a completely separate element. That is because the concept of being optional is orthogonal to scope ... it's perfectly reasonable, for example, to have an optional module with compile scope if your build process knows how to intelligently deal with that combination. PLEASE do not misuse provided scope to mean the optional element or vice versa. PLEASE set up your POMs to say what you mean. These are two DIFFERENT concepts! Craig Bashar -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos Sanchez Sent: Tuesday, February 06, 2007 5:18 PM To: Maven Users List Subject: Re: dependencies are bloated in M2 still not right, you have to use exclusions provided means the environment (read appserver) provides that dependency, which is only true for few dependencies in the whole world, like servlet-api On 2/6/07, Bashar Abdul Jawad [EMAIL PROTECTED] wrote: This is the question I was answering: Tandon, Pankaj wrote: 1. How can we control what get's into WEB-INF/lib. We tried all the scopes mentioned, but that did not help. And it's follow up: Christian Goetze wrote: I believe that the scope that should work is provided. The problem is that I don't know if maven is smart enough to remove a provided dependency from the transitive closure. I would call that a bug if it didn't. And the answer to these 2 questions is to use the provided scope. It will also stop a dependency from being passed on transitively. Using exclusions is NOT right if you still want to compile against these dependencies. Bashar -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos Sanchez Sent: Tuesday, February 06, 2007 5:02 PM To: Maven Users List Subject: Re: dependencies are bloated in M2 exactly, that's why he needs to use exclusions, you exclude things that you don't need. On 2/6/07, Bashar Abdul Jawad [EMAIL PROTECTED] wrote: It is the right solution. Using exclusions will exclude a dependency from being downloaded at all, which means it won't be available at any path. Using provided will still make the dependency available for compile time, but not in runtime, and will not bundle it in the package. Read maven FAQ: http://maven.apache.org/general.html#scope-provided -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos Sanchez Sent: Tuesday, February 06, 2007 4:29 PM To: Maven Users List
RE: dependencies are bloated in M2
Thanks for clearing that up. I think this discussion made it more clear what is the difference among provided, optional and exclusions. Sorry if I confused anyone. Bashar -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Craig McClanahan Sent: Tuesday, February 06, 2007 11:18 PM To: Maven Users List Subject: Re: dependencies are bloated in M2 On 2/6/07, Bashar Abdul Jawad [EMAIL PROTECTED] wrote: Yes, but sometimes you will need to use a dependency for compile time only, and NOT for runtime. You don't need the container to provide it for you either because it is not required for runtime. Example: aspectjtools.jar. You can't exclude it because your project will not compile. The only way is to give it the provided scope. That is not correct. Declaring a dependency to be optional puts it on the compile classpath, but avoids any attempt to include it at runtime. Even if your container doesn't provide it that's not a problem, maven doesn't care. I know it is not very clean to give a dependency a provided scope when it's not going to be provided anywhere, but sometimes you need to do this if you want to compile against it. The semantics of provided are different than optional even though Maven does not enforce it. The code you write against a provided API assumes that the API will indeed be provided by the container. As an example, you might declare as provided a library that you've installed in Tomcat's common/lib directory. The library must be there in order for the application to function -- but Maven can assume that it will indeed by supplied by the container, so won't include it in the WAR. Optional, on the other hand, means what it says. Declaring such a dependency means that you will need it available at compile time FOR THE DEPENDENCY, but not necessarily for your own code (unless you explicitly need it for other reasons). The library is explicitly NOT required at runtime, because your dependency has said, in effect, I can use this library if it exists, but if it does not, no harm no foul. Note also that optional is NOT a scope -- it is a completely separate element. That is because the concept of being optional is orthogonal to scope ... it's perfectly reasonable, for example, to have an optional module with compile scope if your build process knows how to intelligently deal with that combination. PLEASE do not misuse provided scope to mean the optional element or vice versa. PLEASE set up your POMs to say what you mean. These are two DIFFERENT concepts! Craig Bashar -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos Sanchez Sent: Tuesday, February 06, 2007 5:18 PM To: Maven Users List Subject: Re: dependencies are bloated in M2 still not right, you have to use exclusions provided means the environment (read appserver) provides that dependency, which is only true for few dependencies in the whole world, like servlet-api On 2/6/07, Bashar Abdul Jawad [EMAIL PROTECTED] wrote: This is the question I was answering: Tandon, Pankaj wrote: 1. How can we control what get's into WEB-INF/lib. We tried all the scopes mentioned, but that did not help. And it's follow up: Christian Goetze wrote: I believe that the scope that should work is provided. The problem is that I don't know if maven is smart enough to remove a provided dependency from the transitive closure. I would call that a bug if it didn't. And the answer to these 2 questions is to use the provided scope. It will also stop a dependency from being passed on transitively. Using exclusions is NOT right if you still want to compile against these dependencies. Bashar -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos Sanchez Sent: Tuesday, February 06, 2007 5:02 PM To: Maven Users List Subject: Re: dependencies are bloated in M2 exactly, that's why he needs to use exclusions, you exclude things that you don't need. On 2/6/07, Bashar Abdul Jawad [EMAIL PROTECTED] wrote: It is the right solution. Using exclusions will exclude a dependency from being downloaded at all, which means it won't be available at any path. Using provided will still make the dependency available for compile time, but not in runtime, and will not bundle it in the package. Read maven FAQ: http://maven.apache.org/general.html#scope-provided -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos Sanchez Sent: Tuesday, February 06, 2007 4:29 PM To: Maven Users List Subject: Re: dependencies are bloated in M2 that's not the right solution, you have to use exclusions On 2/6/07, Bashar Abdul Jawad [EMAIL PROTECTED] wrote: It will. If you don't want to include a particular dependency in your generated package just
Re: dependencies are bloated in M2
Tandon, Pankaj wrote: So the questions are: 1. How can we control what get's into WEB-INF/lib. We tried all the scopes mentioned, but that did not help. I believe that the scope that should work is provided. The problem is that I don't know if maven is smart enough to remove a provided dependency from the transitive closure. I would call that a bug if it didn't. -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: dependencies are bloated in M2
OK.. I just got the answer to my question 2a on this thread... (The rest are still unanswered). mvn package -X is the most useful command I found to get at the depenceny tree. From there.. it was just a matter of excluding the extra jars. I wish there was a top level exclusion (maybe in the dependencyManagement node where global exclusions could be specified. Thanks Pankaj Christian Goetze-3 wrote: Tandon, Pankaj wrote: So the questions are: 1. How can we control what get's into WEB-INF/lib. We tried all the scopes mentioned, but that did not help. I believe that the scope that should work is provided. The problem is that I don't know if maven is smart enough to remove a provided dependency from the transitive closure. I would call that a bug if it didn't. -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/dependencies-are-bloated-in-M2-tf3182336s177.html#a8836160 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: dependencies are bloated in M2
mvn site see the tree of dependencies use exclusions in your dependencies http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html On 2/6/07, Tandon, Pankaj [EMAIL PROTECTED] wrote: Hi all, We've been using Maven 1.1 for more that a year now and are looking to move to M2. With M1 our project.xml file had dependencies specified explicitly because there was no support for transitive dependencies. As a result, the jar files we downloaded for our webapp weighed in at about 11Meg. While building our M2 pom.xml file(s), we kept adding dependencies (in the pom.xml) till we got a clean compile. However now the size of the dependent artifacts has doubled to a whopping 23Meg! And they make it to the WEB-INF/lib increasing the size of our final artifact. So the questions are: 1. How can we control what get's into WEB-INF/lib. We tried all the scopes mentioned, but that did not help. There used to be a propertieswar.bundletrue/war.bundle/properties in the dependency node in M1, but that is no longer available in M2. So even if I have more depoendencies at compile time, how can I prevent my war artifact from getting bloated? 2. How can we exclude second and third level dependencies. And IF we can do so, how do I know what the dependency graph is for some of the downloaded jars. For instance, there is a jar file (that is about 3Meg in size) called apacheds-core-0.9.jar. We know our app does not need this becuase if we delete this file, the app works just fine. 2a. How do I find out what top level dependecny that is specified in the pom caused a certain file to be downloaded? If we figure that out maybe we can use the exclude element in each dependency to NOT load this dependency. For instance, how do I find out what top level dependency in my pom caused this apacheds-core-0.9.jar to land up in my local repository. Infact, this jar does not even exist on http://repo1.maven.org/maven2/ unless I google it out and find it is tucked away here http://repo1.maven.org/maven2/directory/. 3. Is there a way to go back to explicit dependencies (non-transitive) in the pom.xml? Thanks in advance, Pankaj -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: dependencies are bloated in M2
It will. If you don't want to include a particular dependency in your generated package just give it the provided scope, it will be excluded even if it was a transitive dependency of something else. Bashar -Original Message- From: Christian Goetze [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 06, 2007 2:58 PM To: Maven Users List Subject: Re: dependencies are bloated in M2 Tandon, Pankaj wrote: So the questions are: 1. How can we control what get's into WEB-INF/lib. We tried all the scopes mentioned, but that did not help. I believe that the scope that should work is provided. The problem is that I don't know if maven is smart enough to remove a provided dependency from the transitive closure. I would call that a bug if it didn't. -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: dependencies are bloated in M2
that's not the right solution, you have to use exclusions On 2/6/07, Bashar Abdul Jawad [EMAIL PROTECTED] wrote: It will. If you don't want to include a particular dependency in your generated package just give it the provided scope, it will be excluded even if it was a transitive dependency of something else. Bashar -Original Message- From: Christian Goetze [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 06, 2007 2:58 PM To: Maven Users List Subject: Re: dependencies are bloated in M2 Tandon, Pankaj wrote: So the questions are: 1. How can we control what get's into WEB-INF/lib. We tried all the scopes mentioned, but that did not help. I believe that the scope that should work is provided. The problem is that I don't know if maven is smart enough to remove a provided dependency from the transitive closure. I would call that a bug if it didn't. -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: dependencies are bloated in M2
It is the right solution. Using exclusions will exclude a dependency from being downloaded at all, which means it won't be available at any path. Using provided will still make the dependency available for compile time, but not in runtime, and will not bundle it in the package. Read maven FAQ: http://maven.apache.org/general.html#scope-provided -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos Sanchez Sent: Tuesday, February 06, 2007 4:29 PM To: Maven Users List Subject: Re: dependencies are bloated in M2 that's not the right solution, you have to use exclusions On 2/6/07, Bashar Abdul Jawad [EMAIL PROTECTED] wrote: It will. If you don't want to include a particular dependency in your generated package just give it the provided scope, it will be excluded even if it was a transitive dependency of something else. Bashar -Original Message- From: Christian Goetze [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 06, 2007 2:58 PM To: Maven Users List Subject: Re: dependencies are bloated in M2 Tandon, Pankaj wrote: So the questions are: 1. How can we control what get's into WEB-INF/lib. We tried all the scopes mentioned, but that did not help. I believe that the scope that should work is provided. The problem is that I don't know if maven is smart enough to remove a provided dependency from the transitive closure. I would call that a bug if it didn't. -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: dependencies are bloated in M2
exactly, that's why he needs to use exclusions, you exclude things that you don't need. On 2/6/07, Bashar Abdul Jawad [EMAIL PROTECTED] wrote: It is the right solution. Using exclusions will exclude a dependency from being downloaded at all, which means it won't be available at any path. Using provided will still make the dependency available for compile time, but not in runtime, and will not bundle it in the package. Read maven FAQ: http://maven.apache.org/general.html#scope-provided -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos Sanchez Sent: Tuesday, February 06, 2007 4:29 PM To: Maven Users List Subject: Re: dependencies are bloated in M2 that's not the right solution, you have to use exclusions On 2/6/07, Bashar Abdul Jawad [EMAIL PROTECTED] wrote: It will. If you don't want to include a particular dependency in your generated package just give it the provided scope, it will be excluded even if it was a transitive dependency of something else. Bashar -Original Message- From: Christian Goetze [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 06, 2007 2:58 PM To: Maven Users List Subject: Re: dependencies are bloated in M2 Tandon, Pankaj wrote: So the questions are: 1. How can we control what get's into WEB-INF/lib. We tried all the scopes mentioned, but that did not help. I believe that the scope that should work is provided. The problem is that I don't know if maven is smart enough to remove a provided dependency from the transitive closure. I would call that a bug if it didn't. -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: dependencies are bloated in M2
As Pankaj originally stated: For instance, there is a jar file (that is about 3Meg in size) called apacheds-core-0.9.jar. We know our app does not need this becuase if we delete this file, the app works just fine. He needs to use exclusions for this as he does not need this dependency for anything, in any scope, at any time. Wayne On 2/6/07, Bashar Abdul Jawad [EMAIL PROTECTED] wrote: It is the right solution. Using exclusions will exclude a dependency from being downloaded at all, which means it won't be available at any path. Using provided will still make the dependency available for compile time, but not in runtime, and will not bundle it in the package. Read maven FAQ: http://maven.apache.org/general.html#scope-provided -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos Sanchez Sent: Tuesday, February 06, 2007 4:29 PM To: Maven Users List Subject: Re: dependencies are bloated in M2 that's not the right solution, you have to use exclusions On 2/6/07, Bashar Abdul Jawad [EMAIL PROTECTED] wrote: It will. If you don't want to include a particular dependency in your generated package just give it the provided scope, it will be excluded even if it was a transitive dependency of something else. Bashar -Original Message- From: Christian Goetze [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 06, 2007 2:58 PM To: Maven Users List Subject: Re: dependencies are bloated in M2 Tandon, Pankaj wrote: So the questions are: 1. How can we control what get's into WEB-INF/lib. We tried all the scopes mentioned, but that did not help. I believe that the scope that should work is provided. The problem is that I don't know if maven is smart enough to remove a provided dependency from the transitive closure. I would call that a bug if it didn't. -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: dependencies are bloated in M2
This is the question I was answering: Tandon, Pankaj wrote: 1. How can we control what get's into WEB-INF/lib. We tried all the scopes mentioned, but that did not help. And it's follow up: Christian Goetze wrote: I believe that the scope that should work is provided. The problem is that I don't know if maven is smart enough to remove a provided dependency from the transitive closure. I would call that a bug if it didn't. And the answer to these 2 questions is to use the provided scope. It will also stop a dependency from being passed on transitively. Using exclusions is NOT right if you still want to compile against these dependencies. Bashar -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos Sanchez Sent: Tuesday, February 06, 2007 5:02 PM To: Maven Users List Subject: Re: dependencies are bloated in M2 exactly, that's why he needs to use exclusions, you exclude things that you don't need. On 2/6/07, Bashar Abdul Jawad [EMAIL PROTECTED] wrote: It is the right solution. Using exclusions will exclude a dependency from being downloaded at all, which means it won't be available at any path. Using provided will still make the dependency available for compile time, but not in runtime, and will not bundle it in the package. Read maven FAQ: http://maven.apache.org/general.html#scope-provided -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos Sanchez Sent: Tuesday, February 06, 2007 4:29 PM To: Maven Users List Subject: Re: dependencies are bloated in M2 that's not the right solution, you have to use exclusions On 2/6/07, Bashar Abdul Jawad [EMAIL PROTECTED] wrote: It will. If you don't want to include a particular dependency in your generated package just give it the provided scope, it will be excluded even if it was a transitive dependency of something else. Bashar -Original Message- From: Christian Goetze [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 06, 2007 2:58 PM To: Maven Users List Subject: Re: dependencies are bloated in M2 Tandon, Pankaj wrote: So the questions are: 1. How can we control what get's into WEB-INF/lib. We tried all the scopes mentioned, but that did not help. I believe that the scope that should work is provided. The problem is that I don't know if maven is smart enough to remove a provided dependency from the transitive closure. I would call that a bug if it didn't. -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: dependencies are bloated in M2
On 2/6/07, Carlos Sanchez [EMAIL PROTECTED] wrote: exactly, that's why he needs to use exclusions, you exclude things that you don't need. Exclusions can get you around immediate build problems, but a feedback loop is necessary to improve the state of the world in general, or the problem will just repeat itself the next time. If your project has a dependency x, and that artifact has an optional dependency y, the POM for x should explicity *say* it is optional. That will cause the web project to do the right thing ... *not* copy in the optional dependencies unless you explicitly declare a dependency on them yourself. Thus, people who published depency x in this scenario need to be lobbied to get their POMs fixed in the next version, to stop causing everyone who uses Maven and their x library grief down the road. A classic case that I know of personally :-) is Jakarta Commons Logging, where the 1.1 version of the POM declares a dependency on the servlet API but mistakenly did not declare it to be optional. Yes, you as a user of Commons Logging can use an exclusion to get rid of the unwanted file, but why should you (or anyone else) *have* to? Wouldn't the right thing be to also go file a bug against C-L to fix their blasted POM? (You don't actually have to for this particular scenario ... the POM has been fixed in the trunk and a 1.1.1 release is likely very soon primarily to address this issue ... but my point is in general it is the people who publish broken POMs that should be complained at here, not Maven itself.) Craig McClanahan On 2/6/07, Bashar Abdul Jawad [EMAIL PROTECTED] wrote: It is the right solution. Using exclusions will exclude a dependency from being downloaded at all, which means it won't be available at any path. Using provided will still make the dependency available for compile time, but not in runtime, and will not bundle it in the package. Read maven FAQ: http://maven.apache.org/general.html#scope-provided -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos Sanchez Sent: Tuesday, February 06, 2007 4:29 PM To: Maven Users List Subject: Re: dependencies are bloated in M2 that's not the right solution, you have to use exclusions On 2/6/07, Bashar Abdul Jawad [EMAIL PROTECTED] wrote: It will. If you don't want to include a particular dependency in your generated package just give it the provided scope, it will be excluded even if it was a transitive dependency of something else. Bashar -Original Message- From: Christian Goetze [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 06, 2007 2:58 PM To: Maven Users List Subject: Re: dependencies are bloated in M2 Tandon, Pankaj wrote: So the questions are: 1. How can we control what get's into WEB-INF/lib. We tried all the scopes mentioned, but that did not help. I believe that the scope that should work is provided. The problem is that I don't know if maven is smart enough to remove a provided dependency from the transitive closure. I would call that a bug if it didn't. -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: dependencies are bloated in M2
still not right, you have to use exclusions provided means the environment (read appserver) provides that dependency, which is only true for few dependencies in the whole world, like servlet-api On 2/6/07, Bashar Abdul Jawad [EMAIL PROTECTED] wrote: This is the question I was answering: Tandon, Pankaj wrote: 1. How can we control what get's into WEB-INF/lib. We tried all the scopes mentioned, but that did not help. And it's follow up: Christian Goetze wrote: I believe that the scope that should work is provided. The problem is that I don't know if maven is smart enough to remove a provided dependency from the transitive closure. I would call that a bug if it didn't. And the answer to these 2 questions is to use the provided scope. It will also stop a dependency from being passed on transitively. Using exclusions is NOT right if you still want to compile against these dependencies. Bashar -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos Sanchez Sent: Tuesday, February 06, 2007 5:02 PM To: Maven Users List Subject: Re: dependencies are bloated in M2 exactly, that's why he needs to use exclusions, you exclude things that you don't need. On 2/6/07, Bashar Abdul Jawad [EMAIL PROTECTED] wrote: It is the right solution. Using exclusions will exclude a dependency from being downloaded at all, which means it won't be available at any path. Using provided will still make the dependency available for compile time, but not in runtime, and will not bundle it in the package. Read maven FAQ: http://maven.apache.org/general.html#scope-provided -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos Sanchez Sent: Tuesday, February 06, 2007 4:29 PM To: Maven Users List Subject: Re: dependencies are bloated in M2 that's not the right solution, you have to use exclusions On 2/6/07, Bashar Abdul Jawad [EMAIL PROTECTED] wrote: It will. If you don't want to include a particular dependency in your generated package just give it the provided scope, it will be excluded even if it was a transitive dependency of something else. Bashar -Original Message- From: Christian Goetze [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 06, 2007 2:58 PM To: Maven Users List Subject: Re: dependencies are bloated in M2 Tandon, Pankaj wrote: So the questions are: 1. How can we control what get's into WEB-INF/lib. We tried all the scopes mentioned, but that did not help. I believe that the scope that should work is provided. The problem is that I don't know if maven is smart enough to remove a provided dependency from the transitive closure. I would call that a bug if it didn't. -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: dependencies are bloated in M2
everything you said is right ;) in an ideal world the only reason to use exclusions is if you are not using a portion of the library that the developer consider required for most of the people On 2/6/07, Craig McClanahan [EMAIL PROTECTED] wrote: On 2/6/07, Carlos Sanchez [EMAIL PROTECTED] wrote: exactly, that's why he needs to use exclusions, you exclude things that you don't need. Exclusions can get you around immediate build problems, but a feedback loop is necessary to improve the state of the world in general, or the problem will just repeat itself the next time. If your project has a dependency x, and that artifact has an optional dependency y, the POM for x should explicity *say* it is optional. That will cause the web project to do the right thing ... *not* copy in the optional dependencies unless you explicitly declare a dependency on them yourself. Thus, people who published depency x in this scenario need to be lobbied to get their POMs fixed in the next version, to stop causing everyone who uses Maven and their x library grief down the road. A classic case that I know of personally :-) is Jakarta Commons Logging, where the 1.1 version of the POM declares a dependency on the servlet API but mistakenly did not declare it to be optional. Yes, you as a user of Commons Logging can use an exclusion to get rid of the unwanted file, but why should you (or anyone else) *have* to? Wouldn't the right thing be to also go file a bug against C-L to fix their blasted POM? (You don't actually have to for this particular scenario ... the POM has been fixed in the trunk and a 1.1.1 release is likely very soon primarily to address this issue ... but my point is in general it is the people who publish broken POMs that should be complained at here, not Maven itself.) Craig McClanahan On 2/6/07, Bashar Abdul Jawad [EMAIL PROTECTED] wrote: It is the right solution. Using exclusions will exclude a dependency from being downloaded at all, which means it won't be available at any path. Using provided will still make the dependency available for compile time, but not in runtime, and will not bundle it in the package. Read maven FAQ: http://maven.apache.org/general.html#scope-provided -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos Sanchez Sent: Tuesday, February 06, 2007 4:29 PM To: Maven Users List Subject: Re: dependencies are bloated in M2 that's not the right solution, you have to use exclusions On 2/6/07, Bashar Abdul Jawad [EMAIL PROTECTED] wrote: It will. If you don't want to include a particular dependency in your generated package just give it the provided scope, it will be excluded even if it was a transitive dependency of something else. Bashar -Original Message- From: Christian Goetze [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 06, 2007 2:58 PM To: Maven Users List Subject: Re: dependencies are bloated in M2 Tandon, Pankaj wrote: So the questions are: 1. How can we control what get's into WEB-INF/lib. We tried all the scopes mentioned, but that did not help. I believe that the scope that should work is provided. The problem is that I don't know if maven is smart enough to remove a provided dependency from the transitive closure. I would call that a bug if it didn't. -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: dependencies are bloated in M2
Yes, but sometimes you will need to use a dependency for compile time only, and NOT for runtime. You don't need the container to provide it for you either because it is not required for runtime. Example: aspectjtools.jar. You can't exclude it because your project will not compile. The only way is to give it the provided scope. Even if your container doesn't provide it that's not a problem, maven doesn't care. I know it is not very clean to give a dependency a provided scope when it's not going to be provided anywhere, but sometimes you need to do this if you want to compile against it. Bashar -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos Sanchez Sent: Tuesday, February 06, 2007 5:18 PM To: Maven Users List Subject: Re: dependencies are bloated in M2 still not right, you have to use exclusions provided means the environment (read appserver) provides that dependency, which is only true for few dependencies in the whole world, like servlet-api On 2/6/07, Bashar Abdul Jawad [EMAIL PROTECTED] wrote: This is the question I was answering: Tandon, Pankaj wrote: 1. How can we control what get's into WEB-INF/lib. We tried all the scopes mentioned, but that did not help. And it's follow up: Christian Goetze wrote: I believe that the scope that should work is provided. The problem is that I don't know if maven is smart enough to remove a provided dependency from the transitive closure. I would call that a bug if it didn't. And the answer to these 2 questions is to use the provided scope. It will also stop a dependency from being passed on transitively. Using exclusions is NOT right if you still want to compile against these dependencies. Bashar -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos Sanchez Sent: Tuesday, February 06, 2007 5:02 PM To: Maven Users List Subject: Re: dependencies are bloated in M2 exactly, that's why he needs to use exclusions, you exclude things that you don't need. On 2/6/07, Bashar Abdul Jawad [EMAIL PROTECTED] wrote: It is the right solution. Using exclusions will exclude a dependency from being downloaded at all, which means it won't be available at any path. Using provided will still make the dependency available for compile time, but not in runtime, and will not bundle it in the package. Read maven FAQ: http://maven.apache.org/general.html#scope-provided -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos Sanchez Sent: Tuesday, February 06, 2007 4:29 PM To: Maven Users List Subject: Re: dependencies are bloated in M2 that's not the right solution, you have to use exclusions On 2/6/07, Bashar Abdul Jawad [EMAIL PROTECTED] wrote: It will. If you don't want to include a particular dependency in your generated package just give it the provided scope, it will be excluded even if it was a transitive dependency of something else. Bashar -Original Message- From: Christian Goetze [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 06, 2007 2:58 PM To: Maven Users List Subject: Re: dependencies are bloated in M2 Tandon, Pankaj wrote: So the questions are: 1. How can we control what get's into WEB-INF/lib. We tried all the scopes mentioned, but that did not help. I believe that the scope that should work is provided. The problem is that I don't know if maven is smart enough to remove a provided dependency from the transitive closure. I would call that a bug if it didn't. -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL
Re: dependencies are bloated in M2
build dependencies are added in plugin dependencies section so they don't interfere with your code dependencies On 2/6/07, Bashar Abdul Jawad [EMAIL PROTECTED] wrote: Yes, but sometimes you will need to use a dependency for compile time only, and NOT for runtime. You don't need the container to provide it for you either because it is not required for runtime. Example: aspectjtools.jar. You can't exclude it because your project will not compile. The only way is to give it the provided scope. Even if your container doesn't provide it that's not a problem, maven doesn't care. I know it is not very clean to give a dependency a provided scope when it's not going to be provided anywhere, but sometimes you need to do this if you want to compile against it. Bashar -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos Sanchez Sent: Tuesday, February 06, 2007 5:18 PM To: Maven Users List Subject: Re: dependencies are bloated in M2 still not right, you have to use exclusions provided means the environment (read appserver) provides that dependency, which is only true for few dependencies in the whole world, like servlet-api On 2/6/07, Bashar Abdul Jawad [EMAIL PROTECTED] wrote: This is the question I was answering: Tandon, Pankaj wrote: 1. How can we control what get's into WEB-INF/lib. We tried all the scopes mentioned, but that did not help. And it's follow up: Christian Goetze wrote: I believe that the scope that should work is provided. The problem is that I don't know if maven is smart enough to remove a provided dependency from the transitive closure. I would call that a bug if it didn't. And the answer to these 2 questions is to use the provided scope. It will also stop a dependency from being passed on transitively. Using exclusions is NOT right if you still want to compile against these dependencies. Bashar -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos Sanchez Sent: Tuesday, February 06, 2007 5:02 PM To: Maven Users List Subject: Re: dependencies are bloated in M2 exactly, that's why he needs to use exclusions, you exclude things that you don't need. On 2/6/07, Bashar Abdul Jawad [EMAIL PROTECTED] wrote: It is the right solution. Using exclusions will exclude a dependency from being downloaded at all, which means it won't be available at any path. Using provided will still make the dependency available for compile time, but not in runtime, and will not bundle it in the package. Read maven FAQ: http://maven.apache.org/general.html#scope-provided -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos Sanchez Sent: Tuesday, February 06, 2007 4:29 PM To: Maven Users List Subject: Re: dependencies are bloated in M2 that's not the right solution, you have to use exclusions On 2/6/07, Bashar Abdul Jawad [EMAIL PROTECTED] wrote: It will. If you don't want to include a particular dependency in your generated package just give it the provided scope, it will be excluded even if it was a transitive dependency of something else. Bashar -Original Message- From: Christian Goetze [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 06, 2007 2:58 PM To: Maven Users List Subject: Re: dependencies are bloated in M2 Tandon, Pankaj wrote: So the questions are: 1. How can we control what get's into WEB-INF/lib. We tried all the scopes mentioned, but that did not help. I believe that the scope that should work is provided. The problem is that I don't know if maven is smart enough to remove a provided dependency from the transitive closure. I would call that a bug if it didn't. -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL
Re: dependencies are bloated in M2
I don't undestand this... since when did compile-time libraries become not needed in runtime ? even servlet-api is needed at runtime, its just that they're being provided by the containers. Please use exclusions. From how I see it, let's say we have Artifacts A, B and C. A depends on B and C depends on A. If C doesn't need use the portion of A that uses the library B, then C can put an exclude clause for B in his dependency in A. That will work. But if you put B as provided in A, then that may only be correct for C. What if there is another artifact D that depends on A entirely, including the portion which uses B ? you then add dependency B into D's pom. Then later on, you'll say why does D depend on B? its not logically correct anymore. So using exclusions is more appropriate. Hope that helps. ^_^ Bashar Abdul Jawad wrote: It is the right solution. Using exclusions will exclude a dependency from being downloaded at all, which means it won't be available at any path. Using provided will still make the dependency available for compile time, but not in runtime, and will not bundle it in the package. Read maven FAQ: http://maven.apache.org/general.html#scope-provided -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos Sanchez Sent: Tuesday, February 06, 2007 4:29 PM To: Maven Users List Subject: Re: dependencies are bloated in M2 that's not the right solution, you have to use exclusions On 2/6/07, Bashar Abdul Jawad [EMAIL PROTECTED] wrote: It will. If you don't want to include a particular dependency in your generated package just give it the provided scope, it will be excluded even if it was a transitive dependency of something else. Bashar -Original Message- From: Christian Goetze [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 06, 2007 2:58 PM To: Maven Users List Subject: Re: dependencies are bloated in M2 Tandon, Pankaj wrote: So the questions are: 1. How can we control what get's into WEB-INF/lib. We tried all the scopes mentioned, but that did not help. I believe that the scope that should work is provided. The problem is that I don't know if maven is smart enough to remove a provided dependency from the transitive closure. I would call that a bug if it didn't. -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: dependencies are bloated in M2
On 2/6/07, Bashar Abdul Jawad [EMAIL PROTECTED] wrote: Yes, but sometimes you will need to use a dependency for compile time only, and NOT for runtime. You don't need the container to provide it for you either because it is not required for runtime. Example: aspectjtools.jar. You can't exclude it because your project will not compile. The only way is to give it the provided scope. That is not correct. Declaring a dependency to be optional puts it on the compile classpath, but avoids any attempt to include it at runtime. Even if your container doesn't provide it that's not a problem, maven doesn't care. I know it is not very clean to give a dependency a provided scope when it's not going to be provided anywhere, but sometimes you need to do this if you want to compile against it. The semantics of provided are different than optional even though Maven does not enforce it. The code you write against a provided API assumes that the API will indeed be provided by the container. As an example, you might declare as provided a library that you've installed in Tomcat's common/lib directory. The library must be there in order for the application to function -- but Maven can assume that it will indeed by supplied by the container, so won't include it in the WAR. Optional, on the other hand, means what it says. Declaring such a dependency means that you will need it available at compile time FOR THE DEPENDENCY, but not necessarily for your own code (unless you explicitly need it for other reasons). The library is explicitly NOT required at runtime, because your dependency has said, in effect, I can use this library if it exists, but if it does not, no harm no foul. Note also that optional is NOT a scope -- it is a completely separate element. That is because the concept of being optional is orthogonal to scope ... it's perfectly reasonable, for example, to have an optional module with compile scope if your build process knows how to intelligently deal with that combination. PLEASE do not misuse provided scope to mean the optional element or vice versa. PLEASE set up your POMs to say what you mean. These are two DIFFERENT concepts! Craig Bashar -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos Sanchez Sent: Tuesday, February 06, 2007 5:18 PM To: Maven Users List Subject: Re: dependencies are bloated in M2 still not right, you have to use exclusions provided means the environment (read appserver) provides that dependency, which is only true for few dependencies in the whole world, like servlet-api On 2/6/07, Bashar Abdul Jawad [EMAIL PROTECTED] wrote: This is the question I was answering: Tandon, Pankaj wrote: 1. How can we control what get's into WEB-INF/lib. We tried all the scopes mentioned, but that did not help. And it's follow up: Christian Goetze wrote: I believe that the scope that should work is provided. The problem is that I don't know if maven is smart enough to remove a provided dependency from the transitive closure. I would call that a bug if it didn't. And the answer to these 2 questions is to use the provided scope. It will also stop a dependency from being passed on transitively. Using exclusions is NOT right if you still want to compile against these dependencies. Bashar -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos Sanchez Sent: Tuesday, February 06, 2007 5:02 PM To: Maven Users List Subject: Re: dependencies are bloated in M2 exactly, that's why he needs to use exclusions, you exclude things that you don't need. On 2/6/07, Bashar Abdul Jawad [EMAIL PROTECTED] wrote: It is the right solution. Using exclusions will exclude a dependency from being downloaded at all, which means it won't be available at any path. Using provided will still make the dependency available for compile time, but not in runtime, and will not bundle it in the package. Read maven FAQ: http://maven.apache.org/general.html#scope-provided -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos Sanchez Sent: Tuesday, February 06, 2007 4:29 PM To: Maven Users List Subject: Re: dependencies are bloated in M2 that's not the right solution, you have to use exclusions On 2/6/07, Bashar Abdul Jawad [EMAIL PROTECTED] wrote: It will. If you don't want to include a particular dependency in your generated package just give it the provided scope, it will be excluded even if it was a transitive dependency of something else. Bashar -Original Message- From: Christian Goetze [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 06, 2007 2:58 PM To: Maven Users List Subject: Re: dependencies are bloated in M2 Tandon, Pankaj wrote: So the questions are: 1. How can we control what get's into WEB-INF/lib. We tried all the scopes
