Yes setting the ranges manually is probably the only solution. I already
had to use this for aries in CXF and Camel to make
them compatible to Karaf 2 and 3 at the same time. For this case it
would be nice if we could define some dependency management rules
for the bundle plugin in the parent pom. I dont think this is already
possible but it would be nice to be able to set rules
like ImportRule: org.apache.karaf.* [2.2,4).
So these rules would not directly import packages but instead simply
configure the ranges when the plugin wants to import a package at a
lower level pom.
That would make configuration considerable simpler in each pom.
Christian
Am 04.06.2012 23:02, schrieb Guillaume Nodet:
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
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
