maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Scholte (JIRA)" <j...@codehaus.org>
Subject [jira] (MNG-2205) "provided" scope dependencies must be transitive
Date Sat, 16 Nov 2013 23:48:20 GMT

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

Robert Scholte updated MNG-2205:
--------------------------------

    Description: 
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.

  was:
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.

    
> "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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message