Right, I understand the difference between the scopes. Here's the scenario I don't understand: Project-A has two dependencies: * Project-B (provided) * Project-C (compile) To me, when I say that Project-B is provided, I'm implicitly stating that all of Project-B's transitive dependencies are also provided (if not, Project-B wouldn't work). But Maven seems to think that if Project-B and Project-C share a dependency (say, commons-lang), then that dependency should no longer be consided provided. This doesn't really make sense to me - once something is provided, it's always going to be provided. I ended up adding the exclusions; it wasn't that bad. You can see them here: http://svn.sonatype.org/nexus-plugins/trunk/nexus-crowd-auth/pom.xml. Justin
________________________________ From: Martin Gainty [mailto:[EMAIL PROTECTED] Sent: Monday, November 10, 2008 6:14 PM To: Edelson, Justin Subject: RE: avoid dependency scope "upgrade" * compile This is the default scope, used if none is specified. Compile dependencies are available in all classpaths of a project. Furthermore, those dependencies are propagated to dependent projects. * provided This is much like compile, but indicates you expect the JDK or a container to provide the dependency at runtime. For example, when building a web application for the Java Enterprise Edition, you would set the dependency on the Servlet API and related Java EE APIs to scope provided because the web container provides those classes. This scope is only available on the compilation and test classpath, and is not transitive. * runtime This scope indicates that the dependency is not required for compilation, but is for execution. It is in the runtime and test classpaths, but not the compile classpath. * test This scope indicates that the dependency is not required for normal use of the application, and is only available for the test compilation and execution phases. * system This scope is similar to provided except that you have to provide the JAR which contains it explicitly. The artifact is always available and is not looked up in a repository. * import (only available in Maven 2.0.9 or later) This scope is only used on a dependency of type pom in the <dependencyManagement> section. It indicates that the specified POM should be replaced with the dependencies in that POM's <dependencyManagement> section. Since they are replaced, dependencies with a scope of import do not actually participate in limiting the transitivity of a dependency. if no other scope is specified then scope defaults to compile http://maven.apache.org/guides/introduction/introduction-to-dependency-m echanism.html#Transitive_Dependencies HTH Martin ______________________________________________ Disclaimer and confidentiality note Everything in this e-mail and any attachments relates to the official business of Sender. This transmission is of a confidential nature and Sender does not endorse distribution to any party other than intended recipient. Sender does not necessarily endorse content contained within this transmission. > Subject: avoid dependency scope "upgrade" > Date: Mon, 10 Nov 2008 17:31:37 -0500 > From: [EMAIL PROTECTED] > To: [email protected] > > In a project I'm working on, I have two dependencies, one of which is > provided and one of which is compile scope. They have a number of > dependencies in common and I'm seeing that the transitive provided > dependencies are changed to compile. This seems counter-intuitive to me. > Is there any way to work around it (other than adding excludes)? > > Thanks, > > Justin Edelson > VP, Platform Engineering > MTV Networks Digital > ________________________________ Get 5 GB of storage with Windows Live Hotmail. Sign up today. <http://windowslive.com/Explore/Hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_5g b_112008>
