Hi, is there any concrete problem with this approach? I would like to live with it at least for some releases and then decide upon our experience if it fits. Otherwise it is just a meta-discussion. I see pros and cons on each side.
Let's do a few releases and collect some evidence ;) 2012/11/22 Reto Bachmann-Gmür <[email protected]> > 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 > > > -- Fabian http://twitter.com/fctwitt
