maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Radai Rosenblatt (JIRA)" <>
Subject [jira] Commented: (MNG-2205) "provided" scope dependencies must be transitive
Date Thu, 17 Feb 2011 06:49:22 GMT


Radai Rosenblatt commented on MNG-2205:

here's my use case:
i have a module with "provided" dependencies on jboss modules. my tests deploy code to an
actual jboss server where these "provided" deps exist, but i also have those same provided
dependencies on the test classpath. since im booting jboss embedded (using the arquillian
project) this causes class-loading issues. i would love for those dependencies to simply not
be there during tests.
maybe instead of breaking current behavior (as having "provided" deps on the lass path does
make sense in certain scenarios) it would be possible to add a new scope ? "provided-transitive",
"provided-test" or whatever that would cause dependencies to be "provided" in tests as well

> "provided" scope dependencies must be transitive
> ------------------------------------------------
>                 Key: MNG-2205
>                 URL:
>             Project: Maven 2 & 3
>          Issue Type: Bug
>          Components: Dependencies
>            Reporter: David Boden
>            Priority: Critical
>             Fix For: 3.x / Backlog
>         Attachments:
> 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
> Project C depends upon Project B. Project C declares a "compile" dependency on Project
> 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:
For more information on JIRA, see:


View raw message