I think the issue did just arise with ConfigAdmin when JB tried to upgrade to compendium 4.3 while our implementation of ConfigAdmin is still on 4.2.
The real problem is that using a jar such as the compendium one is against the modularity of OSGi which should have fine grained dependencies on packages. Forcing the use of a given package set for no reasons introduces additional constraints which aren't needed, not desirable. The real problem is version ranges and the fact that if we were to use the maven plugin to generate those (as we do now), we kinda have to keep the lowest compatible one, while at runtime, we kinda want the latest one. But i don't think solving this issue by having two set of dependencies would really help, so that's why I suggested manually managing the ranges in the pom when needed. On Mon, Jun 4, 2012 at 8:37 PM, Christian Schneider <[email protected]> wrote: > Interesting problem. In this case depending on the impl is surely the > easiest solution at least if the impl exactly includes the needed APIs. > I guess it is not a general solution though. If you depend on more than one > impl and they use different versions of the same API you soon end up in the > same situation. > > Does this issue already happen with the config admin alone? So does it use > different versions of compendium APIs? If yes I strongly suggest to solve > this directly in config admin as I guess this will cause > problems for anyone using it. So maybe we could either skip this config > admin service version or depend on the impl for some time and switch back to > the API as soon as this is solved in config admin service. > In any case I think we should at least document somewhere why we use an impl > dependency. So a reader of the code who missed the discussion knows why. > This might then be a nice addition to the architectural decisions page in > the wiki. > > In general depending on different versions of compendium jars should even > possible if necessary. As we use the "provided" scope the dependency should > not be transitive. > > Christian > > Am 04.06.2012 18:41, schrieb Guillaume Nodet: > >> Well, the whole thing started with an issue JB had because there was a >> mismatch between the compendium jar (hence the version range) and the >> config admin at runtime, and those were incompatible. The problem is >> that the compendium is homogeneous, and we may depend on some version >> of a given service and other for other services, so using compendium >> forbids that. Also, I usually hate having multiple versions of the >> same package in my dependency tree when I can avoid it. >> >> On Mon, Jun 4, 2012 at 6:25 PM, Christian Schneider >> <[email protected]> wrote: >>> >>> That is right but is it a big issue to just depend on the whole >>> compendium >>> jar at build time in maven? The bundle plugin will only import the needed >>> packages >>> for runtime anyway. >>> >>> Christian >>> >>> Am 04.06.2012 17:41, schrieb Guillaume Nodet: >>>> >>>> That's true but unfortunately I'm not aware of any jar providing just >>>> the >>>> api for a given osgi service. >>>> >>>> On Monday, June 4, 2012, Christian Schneider wrote: >>>> >>>>> I think we should not depend on an implementation if there is an API. >>>>> The >>>>> implementation can bring in unwanted transitive depencies that are much >>>>> worse than managing the package dependencies. >>>>> At runtime it can be enough to install the impl of course if it brings >>>>> along the api. >>>>> >>>>> Christian >>>>> >>>>> >>>>> Am 04.06.2012 09:43, schrieb Jean-Baptiste Onofré: >>>>> >>>>>> Hi all, >>>>>> >>>>>> I updated Karaf trunk (3.0) to use OSGi Compendium 4.3.0. It means >>>>>> that >>>>>> now, Karaf trunk uses both OSGi and OSGi Compendium 4.3.0 (whereas >>>>>> previously it used OSGi 4.3.0 and OSGi Compendium 4.2.0). >>>>>> >>>>>> However, to "simplify" version range, I think it makes sense to not >>>>>> depend from OSGi Compendium but directly from the service >>>>>> implementation >>>>>> itself (for instance Felix ConfigAdmin, etc). As we already manage the >>>>>> version of service implementation, I think OSGi compendium dependency >>>>>> is >>>>>> superfluous. >>>>>> >>>>>> I raised: >>>>>> >>>>>> >>>>>> https://issues.apache.org/**jira/browse/KARAF-1518<https://issues.apache.org/jira/browse/KARAF-1518> >>>>>> >>>>>> >>>>>> WDYT ? >>>>>> >>>>>> Thanks >>>>>> Regards >>>>>> JB >>>>>> >>>>> -- >>>>> Christian Schneider >>>>> http://www.liquid-reality.de >>>>> >>>>> Open Source Architect >>>>> Talend Application Integration Division http://www.talend.com >>>>> >>>>> >>> >>> -- >>> Christian Schneider >>> http://www.liquid-reality.de >>> >>> Open Source Architect >>> Talend Application Integration Division http://www.talend.com >>> >> >> > > > -- > > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > Talend Application Integration Division http://www.talend.com > -- ------------------------ Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ FuseSource, Integration everywhere http://fusesource.com
