Hi, The concrete problem: I've made changes to the WebFragment interface (in org.apache.stanbol.commons.web.base). The classes implementing it no longer compile if they have proper @Override annotations. Packages which used to implement the old version should remove the method and move the templates to another location.
At runtime implementation of the old interface still work except that the method is never invoked and the templates are looked up in the new location. I've moved the templates to the new location in all modules and I've removed the method in those modules dependeing on the trunk version. The other modules are now in the state that they work only with the trunk launchers but compile only with the dependency to the old comms.web.base. If developer update the dependency version they'll have to find out why it fails and what adaptations are needed. I think it would be much more efficient if the one that changes an interface also changes all dependencies in trunk to compile with the new version. Of course one could just update the modules depending on the updated one to use the latest version. Howver I think it would be more consistent to keep the reactor modules to depend on the latest versions, this can be done running and needs no change to depenedency management: mvn org.codehaus.mojo:versions-maven-plugin:1.3.1:use-latest-versions "-Dincludes=org.apache.stanbol:*:*:*" -DallowSnapshots=true -DexcludeReactor=false For the following modules we have other modules depending of older versions of them: org.apache.stanbol.commons.jsonld org.apache.stanbol.commons.solr.core org.apache.stanbol.commons.stanboltools.datafileprovider org.apache.stanbol.commons.stanboltools.offline org.apache.stanbol.commons.web.base org.apache.stanbol.entityhub.core org.apache.stanbol.entityhub.model.clerezza org.apache.stanbol.entityhub.servicesapi org.apache.stanbol.entityhub.yard.solr Given that in the launchers the reactor build they have to be compatible with the latest versions anyway this seems inconsistent to me. For now I'll just update the modules to depend on the latest version of org.apache.stanbol.commons.web.base. Cheers, Reto On Fri, Nov 23, 2012 at 9:15 AM, Fabian Christ <[email protected] > wrote: > 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 >
