Return-Path: Delivered-To: apmail-maven-users-archive@www.apache.org Received: (qmail 18500 invoked from network); 7 Feb 2007 16:29:42 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 7 Feb 2007 16:29:42 -0000 Received: (qmail 50091 invoked by uid 500); 7 Feb 2007 16:29:41 -0000 Delivered-To: apmail-maven-users-archive@maven.apache.org Received: (qmail 50039 invoked by uid 500); 7 Feb 2007 16:29:41 -0000 Mailing-List: contact users-help@maven.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Help: List-Post: List-Id: "Maven Users List" Reply-To: "Maven Users List" Delivered-To: mailing list users@maven.apache.org Received: (qmail 50028 invoked by uid 99); 7 Feb 2007 16:29:41 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 07 Feb 2007 08:29:41 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: local policy) Received: from [216.169.140.132] (HELO jabba.vmsinfo.com) (216.169.140.132) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 07 Feb 2007 08:29:31 -0800 Received: from nyc-mailbox-03.vmsinfo.com (localhost.localdomain [127.0.0.1]) by jabba.vmsinfo.com (8.12.8/8.12.8) with ESMTP id l17GTA5A018410 for ; Wed, 7 Feb 2007 11:29:10 -0500 Received: from TUCWKSWXP4029 (localhost.localdomain [127.0.0.1]) by nyc-mailbox-03.vmsinfo.com (8.12.11/8.12.10) with ESMTP id l17GT8b1013698 for ; Wed, 7 Feb 2007 11:29:09 -0500 From: "Bashar Abdul Jawad" To: "'Maven Users List'" References: <6F378D0441CD8A4CA97F6E42C0E5FED7064E7537@ccicusmsx2.us.crowncastle.com> <45C8FA02.1000008@miaow.com> <001001c74a44$fc310110$2201010a@vtdom.local> <1a5b6c410702061529p2d058b55ke7d42cf6c4edfb5d@mail.gmail.com> <001101c74a49$2bc94ff0$2201010a@vtdom.local> <1a5b6c410702061602o4dae0363nbc6ce235c8e248b1@mail.gmail.com> <001601c74a4c$fd7d5d90$2201010a@vtdom.local> <1a5b6c410702061617oa52f24dhe0d108d13d6884a8@mail.gmail.com> <001a01c74a51$500cefe0$2201010a@vtdom.local> Subject: RE: dependencies are bloated in M2 Date: Wed, 7 Feb 2007 09:32:11 -0700 Message-ID: <002401c74ad5$8517fde0$2201010a@vtdom.local> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdKf9K5Xh9fFEDVSgeHN+9b/y3NZgAVTRXw X-Virus-Checked: Checked by ClamAV on apache.org 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: craigmcc@gmail.com [mailto:craigmcc@gmail.com] 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 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: carlossg@gmail.com [mailto:carlossg@gmail.com] 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 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: carlossg@gmail.com [mailto:carlossg@gmail.com] 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 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: carlossg@gmail.com [mailto:carlossg@gmail.com] 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 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:cg@miaow.com] > > > > 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: users-unsubscribe@maven.apache.org > > > > For additional commands, e-mail: users-help@maven.apache.org > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org > > > > For additional commands, e-mail: users-help@maven.apache.org > > > > > > > > > > > > > > > > > -- > > > I could give you my word as a Spaniard. > > > No good. I've known too many Spaniards. > > > -- The Princess Bride > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org > > > For additional commands, e-mail: users-help@maven.apache.org > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org > > > For additional commands, e-mail: users-help@maven.apache.org > > > > > > > > > > > > -- > > I could give you my word as a Spaniard. > > No good. I've known too many Spaniards. > > -- The Princess Bride > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org > > For additional commands, e-mail: users-help@maven.apache.org > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org > > For additional commands, e-mail: users-help@maven.apache.org > > > > > > > -- > I could give you my word as a Spaniard. > No good. I've known too many Spaniards. > -- The Princess Bride > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org > For additional commands, e-mail: users-help@maven.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org > For additional commands, e-mail: users-help@maven.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@maven.apache.org For additional commands, e-mail: users-help@maven.apache.org