THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
To handle these cases, those plugins which don't compile after the bundle builds the manifest.mf, because they are missing includes, have the required includes added to the POM.
Scopes and <optional> in dependencies
Scopes are used to control dependency transitivity and to set up classpaths, and for other things (other plugins can behave differently depending on scope).
We make our Eclipse dependencies "provided", and our uima dependencies "compile". This makes the eclipse:eclipse plugin create links for the uima dependencies to the local maven repo for the jars, and puts these on the classpath. The Eclipse dependencies are "provided" - meaning they come from the OSGi container (the current Eclipse runtime environment).
When building bundles, typically scopes used are:
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" |
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.
I 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).