[ 
http://jira.codehaus.org/browse/MNG-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=205573#action_205573
 ] 

Denis Kramer commented on MNG-2205:
-----------------------------------

I believe the right behavior is postulated in the Maven Scope Matrix 
(http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html).

There a combination of provided/provided (for dependency and a dependency in 
the dependency) leads to a provided scope for the secondary dependency (as it 
should be).

I'm not entirely sure if a xxx/provided dependency should be transitive. 
Thinking about OSGi environments, this might lead to version issues. 

Anyway, maven (as of 2.2.1) does not even handle the provided/provided case as 
given in the Maven Scope Matrix.


> "provided" scope dependencies must be transitive
> ------------------------------------------------
>
>                 Key: MNG-2205
>                 URL: http://jira.codehaus.org/browse/MNG-2205
>             Project: Maven 2 & 3
>          Issue Type: Bug
>          Components: Dependencies
>            Reporter: David Boden
>            Priority: Critical
>             Fix For: 3.x
>
>
> A provided scope dependency can also be thought of as "compile-only".
> Project A requires Sybase JConnect on the runtime classpath. Project A 
> declares a "provided" dependency on Sybase JConnect.
> Project B depends upon Project A. Project B declares a "compile" dependency 
> on Project A.
> Project C depends upon Project B. Project C declares a "compile" dependency 
> on Project B.
> C
> | - compile dependency
> B
> | - compile dependency
> A
> | - provided dependency
> Sybase JConnect
> So, does Project C transitively depend on Sybase JConnect. Yes, of course! 
> The "provided" dependency needs to be transitive.
> Ultimately, when Project C gets deployed, Sybase JConnect needs to be 
> somewhere on the runtime classpath in order for the application to function. 
> It's valid for Project C to assume that Sybase JConnect is available and use 
> JDBC all over the Project C code. Project C is safe to do this because it can 
> happily deduce that Sybase JConnect will be there in the runtime environment 
> because Project A NEEDS IT.
> I've got Use Cases all over my aggregated build which make it absolutely 
> critical and common sense that provided scope dependencies are transitive. 
> For the (very rare) odd case where you don't want to inherit provided 
> dependencies, you can <exclude/> them.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to