[
https://issues.apache.org/jira/browse/MNG-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16267311#comment-16267311
]
Chris Povirk commented on MNG-2205:
-----------------------------------
I think that most of the reasons given here are bad reasons. Still, I think
there are good reasons to want a new "transitive compile-time" scope.
Primarily, it's about annotations: A project may want to depend on some
annotations at compile time but might not use them at runtime. In the simplest
case, the annotations may have only source retention, so they're provably
unusable at runtime.
Yet they may still be needed when compiling transitive users: If you build
against a library that uses annotations but the annotations aren't present,
javac sometimes issues warnings. And if you're the kind of person who uses
{{-Xlint:all -Werror}}, your build breaks. (And I don't think it's possible to
suppress that kind of warning without also suppressing others.) For example:
{{Cannot find annotation method 'value()' in type
'com.google.errorprone.annotations.CompatibleWith': class file for
com.google.errorprone.annotations.CompatibleWith not found}}
This means that {{optional}} and {{provided}} are both insufficient. As a
result, we include the dependencies at runtime, too. Users then have to
manually exclude them to avoid the extra classes.
Another use case: Static analysis tools (e.g., [Error
Prone|http://errorprone.info/]) may expect transitive dependencies to be
present at compile-time. If the dependencies aren't there, the tool may crash.
In the case of Error Prone, the tool owners have been willing to work around
these problems, but the cost is that the tool may have to skip files and thus
miss errors.
The background here is that we've had exactly these problems with
[Guava|https://github.com/google/guava]. See
[#2721|https://github.com/google/guava/issues/2721],
[#2824|https://github.com/google/guava/issues/2824], and [this discussion on
our latest
release|https://groups.google.com/d/msgid/guava-discuss/1e3b98f1-daf0-4c83-8cb5-9a5c1e70ec10%40googlegroups.com?utm_medium=email&utm_source=footer].
> "provided" scope dependencies must be transitive
> ------------------------------------------------
>
> Key: MNG-2205
> URL: https://issues.apache.org/jira/browse/MNG-2205
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
> Reporter: David Boden
> Priority: Critical
> 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 was sent by Atlassian JIRA
(v6.4.14#64029)
