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

Tibor Digana commented on MNG-2205:
-----------------------------------

@Jason
The problem is that the behavior has changed after Maven 2.2.1.
New keywords would not be acceptable by the community in my guess - this may 
take quite long time to implement and finally the Maven users may get lost.
I prefer simplicity and correct behavior against huge number of keywords.
The right solution would be to concentrate on fixing hunderds of bugs in the 
Maven project. First of all to write tests against Maven 2 behavior and then 
run the same tests on Maven 3, let's see what will happen.

> "provided" scope dependencies must be transitive
> ------------------------------------------------
>
>                 Key: MNG-2205
>                 URL: https://jira.codehaus.org/browse/MNG-2205
>             Project: Maven 2 & 3
>          Issue Type: Bug
>          Components: Dependencies
>            Reporter: David Boden
>            Priority: Critical
>             Fix For: 3.x / Backlog
>
>         Attachments: transitivetest.zip
>
>
> 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.
> {noformat}
> C
> | - compile dependency
> B
> | - compile dependency
> A
> | - provided dependency
> Sybase JConnect
> {noformat}
> 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 was sent by Atlassian JIRA
(v6.1.6#6162)

Reply via email to