I agree that if integration offer full coverage the will fail when a compatibility breaking change is introduced. However the advantage of statically typed languages is that you can detect this problems already at compile time.
The two arguments you mention package split and interaction with host environment are in fact arguments for having all modules depend on the same versions of their dependencies. As in the trunk launchers we use the trunk versions these modules should also depend exclusively of the trunk versions of other stanbol modules. Embedding is an import usecase that should be supported, the easiest way to address it is to have just one version of the bundles and consistent dependencies. Backward compatibility (e.g. that somebody wants to use an old version of an engine with a new enhancer) seems less important and to provide this the current approach of having engines compile but then fail at runtime doesn't seem a good approach anyway. Cheers, Reto On Wed, Nov 21, 2012 at 11:25 PM, Rupert Westenthaler < [email protected]> wrote: > > 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 >
