[
http://jira.codehaus.org/browse/MNG-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=131081#action_131081
]
bugittaa edited comment on MNG-2205 at 4/17/08 1:55 AM:
----------------------------------------------------------------
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.
edit: this seem to be bit more complicated than that: how about classpath for
compiling and running tests etc.
As a quick thought, classpath for compiling tests could be just the direct
dependencies and for running tests same as for packaging (but how about
transitive test dependencies)?
was (Author: bugittaa):
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
