You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by "Edelson, Justin" <Ju...@mtvstaff.com> on 2008/11/10 23:31:37 UTC

avoid dependency scope "upgrade"

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
 

RE: avoid dependency scope "upgrade"

Posted by "Edelson, Justin" <Ju...@mtvstaff.com>.
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:mgainty@hotmail.com] 
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: Justin.Edelson@mtvstaff.com
> To: users@maven.apache.org
> 
> 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>