[
http://jira.codehaus.org/browse/MNG-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_101936
]
David Boden commented on MNG-2205:
----------------------------------
The problem is that project C is not able to use JConnect classes directly.
It's not on project C's compile classpath.
Why not? Why not indeed. It should be! That's what this bug is aiming to fix.
JConnect is a bad example, because you typically don't access JConnect classes
directly, you're more likely to use the JDBC API and hide the implementation
details.
Eclipse RCP is a better example (it's a real world example for me). Project A
is an Eclipse RCP component. It's used by Project B which is in turn used by
Project C. Now, because of the way we package the application, the Eclipse RCP
(big) jar files are downloaded separately and are provided for the distribution
of my application. The problem is that why should I explicitly declare a
dependency from Project C to Eclipse RCP? It should be inherited transitively.
The default behaviour should be that I can use the Eclipse RCP API in Project C.
> "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.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
