[jira] Commented: (MNG-2205) "provided" scope dependencies must be transitive

["Bugittaa Pahasti (JIRA)" <ji...@codehaus.org>]

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

Bugittaa Pahasti commented on MNG-2205:
---------------------------------------

I think distinguishing packaging and compiling would make sense here. I use compile scope as an example:

- for direct dependencies it's clear that they are included in you compile time classpath and also included when packaged to a war for example.
- for transitive dependencies, it's clear they should be packaged but the question is if they should be included in the compile time classpath.

Ok, let's have an example:

*1. Current behavior:*
A -> B (compile) -> C (compile)
A -> B (compile) -> D (provided)

C: included in A's compile classpath, included in packaging
D: not included in A's compile classpath, not packaged

*2. Requested in this issue:*
A -> B (compile) -> C (compile)
A -> B (compile) -> D (provided)

C: included in A's compile classpath, included in packaging
D: *included* in A's compile classpath, not packaged

*3. Preferable solution in my opinion:*
A -> B (compile) -> C (compile)
A -> B (compile) -> D (provided)

C: *not included* in A's compile classpath, included in packaging
D: not included in A's compile classpath, not packaged

If I remember correctly there were some talk in the mailing list that maven 2.1 would implement option 3, but I might remember wrong.


> "provided" scope dependencies must be transitive
> ------------------------------------------------
>
>                 Key: MNG-2205
>                 URL: http://jira.codehaus.org/browse/MNG-2205
>             Project: Maven 2
>          Issue Type: Bug
>          Components: Dependencies
>            Reporter: David Boden
>            Priority: Critical
>             Fix For: 2.1
>
>
> 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