You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Michael Pollmeier (JIRA)" <ji...@codehaus.org> on 2010/12/17 17:51:03 UTC

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

     [ http://jira.codehaus.org/browse/MNG-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Pollmeier updated MNG-2205:
-----------------------------------

    Attachment: transitivetest.zip

This 'critical' issue seems to be dead somehow, so I thought I put in my 2 pence and a bugfix.

First a short summary to the problem as it was a bit blurry in all the various comments: I believe (and I'm not alone there) that we need to make provided dependencies transitive. This is how it used to be in the dependency matrix, however it was never implemented that way, hence this issue was created. Instead of solving it by changing the code, the dependency matrix has been amended to indicate that provided dependencies are _not_ transitive. This has happened silently, at least no comment was left in this issue regarding that change of the documentation. 

Let me point out why provided dependencies should be transitive with a simple example using the projects A, B and C: 
A doesn't depent on anything. B depends on A. And C depends on B. 
Now you want to run unit or integration tests on C. It is straightforward to see that C _must_ have a transitive provided dependency on A, because B (which C depends on) _needs_ A to function. Therefore A must be in the classpath, right? With the current implementation, A will not be in the dependency scope of maven at all, because provided dependencies are not regarded as transitive dependencies. 

Also the combination compile/optional is not a workaround, as it basically duplicates the provided scope - I however can't see a difference in behaviour between 'compile/optional' and 'provided'.

I'll attach these 'A,B,C' poms so that you can play around yourself. 

As a possible resolution I forked mvn in github and provide a bugfix commit:
https://github.com/mpollmeier/maven-3/commit/3339789d6ae2dcbdc0e98d7b47a18f8a2aa2893e

Please let me know your thoughts and pull the change if you like it. 

> "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 / 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.
> 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