On 8/15/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
The said article mentions the notion of "runtime classpath." While I
can see what compile and test classpaths mean, I fail to understand
what a runtime classpath is, in particular how it differs from the
test classpath.
Think of Runtime as somewhat of an optimization for the build process.
The jar itself is not needed to compile the code as it has no direct
dependency on it, though the code itself still needs this jar to
execute, as such it will travel along transitively in case it is
needed down the line, and will also be included in the test scope as
it may be called upon since the code has a runtime dependency on it.
Moreover, the article defines "provided scope" as follows:
provided - this is much like compile, but indicates you expect theJDK
or a container to provide it. It is only available on the compilation
classpath, and is not transitive.
However, in a small project I've created to test dependency scopes, it
seems that a dependency declared with the "provided" scope is
available when compiling the source, compiling the test cases as well
as when running them (the test cases). Thus, it looks like the
provided scope is the same as the compile scope, except that the
provided scope is not transitive.
The documentation may be slightly wrong, as you experienced the
provided scope jars are available to tests (at least in my
experience), though I believe only that local project tests, as you
have no transitivity (I may be wrong here, corrections?). Provided is
very much like compile w/o transitivity. It is assumed that your
container or system will provide this jar when needed.
The difference between the runtime and test scopes is also not very
clear to me.
This was already answered, but the test dependencies aren't needed for
"normal" runtime, so they are left out. It allows you to pull in a
test harness, or mock libraries during your tests but leave that out
for "real" execution or packaging.
The small table which illustrates the effects of scopes on
transitivity is not easy to grok. In particular, the explanation
(quoted below) preceding the table does not define the direction of
any of the dependencies.
I'm guessing it's trying to tell you the precidence of dependencies
when the same dependency is referenced in multiple scopes in one
project, but you're right, the preceeding paragraph is not exactly
clear in what it is talking about.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
