> But I think they should nevertheless be kept up to date as
> otherwise we have no compile time check that the module will indeed work in
> the trunk version of the launcher. So I think we should regularly run a
UnitTest are executed using compile time dependencies
Integration test do check the runtime dependencies.
So I do not see a problem with that.
In addition one has to consider that the OSGI dependency management is
anyway different from the maven one.
To give two examples (for details have a look at the Semantic
Versioning Whitepaper [1])
1. consumer and provider policy: Stanbol uses (since STANBOL-774)
-provider-policy : ${range;[==,=+)}
-consumer-policy : ${range;[==,+)}
That means that by default dependencies do use a version range of
[==,+). However this is not feasible for imported packages that are
implemented by an module, as minor versions may e.g. extend an
interface by an additional method. So for such cases the import needs
to be marked with the provider-policy to ensure [==,=+).
2. Dependency management in maven is on module level where for OSGI
uses a package level granularity.
Depending on the latest version undermines version ranges (especially
for consumer-policy dependencies) - [==,=+) where the left side is the
most current version means basically that there is no version range at
all.
- - -
While such things are not really visible as long as you run everything
within the OSGI environment it starts really to hurt as soon as you
want to access services form outside of OSGI (e.g. when you run
Stanbol in an embedded OSGI environment). In such settings one needs
to expose all packages of used interfaces via the system bundle and
therefore you do not have the possibility to use different versions of
the same class.
But also within OSGI there are some disadvantages one might encounter.
One example is a fragmentation of the service registry (basically a
bundle may not use a service, because it's version of the Interface
was loaded using a different classloader as the version of the
Interface provided by the Service). If that happens ServiceTracker
will not get notified for available services - because they would not
be compatible. Debugging that is not fun and solving such issues is
only possible by fixing version ranges.
I agree that out of an maven and build perspective this might look
like a bad choice, but from the OSGI perspective it is exactly how it
should be done.
I think the version number confusion of sling is caused by the fact
the every single module can have totally different versions. I think
in Stanbol this can be easily avoided by ensuring that all modules of
a Stanbol component (enhancer, entityhub, ... ) are all within
[==,=+). For the commons stuff we could use the same rule but one
level below (e.g. that all commons.solr modules are within [==,=+))
best
Rupert
[1] http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf
--
| Rupert Westenthaler [email protected]
| Bodenlehenstraße 11 ++43-699-11108907
| A-5500 Bischofshofen
