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
