THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
scope | meaning |
|---|---|
"compile" | contains classes/resources being embedded because my code needs them to load and I don't expect them to be provided by another bundle. |
"runtime" | contains classes/resources that to embed because my code might need them during runtime (via reflection, etc.) and I don't expect them to be provided by another bundle |
"provided" | contains classes/resources that I expect to be provided by another bundle or the framework |
"test" | contains classes/resources used in any unit or integration tests (ie. not needed to load/run the bundle - just needed to test with) |
It also says, for "provided" that "it is not transitive", but in the
> > next paragraph, it shows "provided" as being transitive for all scopes
> > (in the referenced POM) except test. This seems contradictory?
yes, I really dislike that table - here's how it works in practice:
A
"compile" |
"provided" |
"provided" |
Scopes and transitivity
Here's how they work in practice. Consider 4 components, A, B, C, & D, where A is stand-alone, B depends on A, C depends on B and D depends on C.
Dependency | Scope | resulting classpath | |
|---|---|---|---|
B -> A | compile | B, A | |
C -> B | provided | C, B, A | because B is compile scoped to A |
D -> C | provided | D, C | because C is provided scoped to B |
Any any dependencies of a "provided" dependency are treated as
if they were also "provided" in later projects - so A is treated
as a "provided" dependency in C, which then means it doesn't
appear in D because "provided" dependencies aren't transitive.
I think the table should really show '-' for 'provided x provided'
just to make things a bit more confusing, you can also mark
dependencies as "optional" which means they are excluded
by default from other projects depending on your project.
<optional>
If you mark a dependency <optional>, this breaks the transitivity for other components that depend on the POM containing the <optional>. If you have a compile|runtime scope dependency, but you don't need components which depend on you to depend also on what you have as a compile|runtime scope dependency on, use the <optional> to break the dependency.
For plugins, if you include the code of a dependency directly into the plugin, then you mark that dependency <optional>. This saves builds that use your component from downloading dependencies they won't useI always mark my "compile" and "runtime" dependencies as
optional, because I expect to embed them inside the bundle
and don't want them exposed to projects depending on my
bundle (saves downloading dependencies you won't use).