Hi Reto,
if you make incompatible changes to an module than you need to adapt
all dependent modules and update the dependency of them to the current
version.
Normally the
-provider-policy : ${range;[==,=+)}
-consumer-policy : ${range;[==,+)}
would ensure that release Bundles are not affected by that. This is
also the reason why for an incompatible API change a major version
increase is required. However for pre 1.0.0 versions this is not the
case.
best
Rupert
On Fri, Nov 23, 2012 at 11:10 AM, Reto Bachmann-Gmür <r...@apache.org> wrote:
> 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 <christ.fab...@googlemail.com
>> 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 <r...@wymiwyg.com>
>>
>> > 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 <
>> > rupert.westentha...@gmail.com> 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 rupert.westentha...@gmail.com
>> > > | Bodenlehenstraße 11 ++43-699-11108907
>> > > | A-5500 Bischofshofen
>> > >
>> >
>>
>>
>>
>> --
>> Fabian
>> http://twitter.com/fctwitt
>>
--
| Rupert Westenthaler rupert.westentha...@gmail.com
| Bodenlehenstraße 11 ++43-699-11108907
| A-5500 Bischofshofen
