You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@karaf.apache.org by Jean-Baptiste Onofré <jb...@nanthrax.net> on 2012/06/04 09:43:51 UTC
[PROPOSAL] Do not depend to OSGi Compendium
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
WDYT ?
Thanks
Regards
JB
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: [PROPOSAL] Do not depend to OSGi Compendium
Posted by Christian Schneider <ch...@die-schneider.net>.
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
> <ch...@die-schneider.net> 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
>>> <ch...@die-schneider.net> 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
Re: [PROPOSAL] Do not depend to OSGi Compendium
Posted by Guillaume Nodet <gn...@gmail.com>.
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
<ch...@die-schneider.net> 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
>> <ch...@die-schneider.net> 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
Re: [PROPOSAL] Do not depend to OSGi Compendium
Posted by Christian Schneider <ch...@die-schneider.net>.
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
> <ch...@die-schneider.net> 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
Re: [PROPOSAL] Do not depend to OSGi Compendium
Posted by Guillaume Nodet <gn...@gmail.com>.
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
<ch...@die-schneider.net> 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
>
--
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
FuseSource, Integration everywhere
http://fusesource.com
Re: [PROPOSAL] Do not depend to OSGi Compendium
Posted by Christian Schneider <ch...@die-schneider.net>.
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
Re: [PROPOSAL] Do not depend to OSGi Compendium
Posted by Guillaume Nodet <gn...@gmail.com>.
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
>
>
--
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
FuseSource, Integration everywhere
http://fusesource.com
Re: [PROPOSAL] Do not depend to OSGi Compendium
Posted by Christian Schneider <ch...@die-schneider.net>.
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
>
> WDYT ?
>
> Thanks
> Regards
> JB
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
Re: [PROPOSAL] Do not depend to OSGi Compendium
Posted by Freeman Fang <fr...@gmail.com>.
yep, +1 for it.
Freeman
On 2012-6-4, at 下午4:52, Guillaume Nodet wrote:
> If we are to define manual version ranges, we need to do that
> centralized in the root pom, at the same location where dependencies
> versions are defined.
>
> On Mon, Jun 4, 2012 at 10:41 AM, Christian Schneider
> <ch...@die-schneider.net> wrote:
>> Some time ago I would have said to let the bundle plugin do its thing
>> automatically. The aries 1.0.0 problem shows that this is not
>> possible in
>> all cases.
>> The minimum version problem like described in the original mail is
>> another
>> issue.
>>
>> So I am +0.5 for having special settings. My main concern is that
>> it is a
>> lot of manual work and we might easily do it wrong on occasion.
>> Still the
>> advantages top this.
>>
>> Christian
>>
>> Am 04.06.2012 10:33, schrieb Achim Nierbeck:
>>
>>> +1 for the initial question regarding compendium.
>>> +1 for defining the version range when using the maven plugin.
>>> Even if
>>> this troubles some that it doesn't work with the "out-of-the-box
>>> way"
>>> it's much cleaner if we define the valid version ranges.
>>>
>>> regards, Achim
>>>
>>>
>>
>> --
>> 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
---------------------------------------------
Freeman Fang
FuseSource
Email:ffang@fusesource.com
Web: fusesource.com
Twitter: freemanfang
Blog: http://freemanfang.blogspot.com
http://blog.sina.com.cn/u/1473905042
weibo: http://weibo.com/u/1473905042
Re: [PROPOSAL] Do not depend to OSGi Compendium
Posted by Achim Nierbeck <bc...@googlemail.com>.
Hi Andreas,
yes to my understanding this was only for versions where we need
ranges, not all :)
regards, Achim
2012/6/4 Andreas Pieber <an...@gmail.com>:
> From my side too + 1 to both proposals.
>
> I don't think that the additional version ranges will produce too much work
> IIF we're able to keep those versions together in the form of properties.
>
> E. G.
>
> Pax. Web. Version...
> Pax. Web. Range...
>
> That way we'll always be reminded if we update one. In addition I think we
> can introduce them on demand and don't have to do it all at once.
>
> Kind regards, Andreas
> On Jun 4, 2012 11:47 AM, "Ioannis Canellos" <io...@gmail.com> wrote:
>
>> I think that it does make sense without add too much effort.
>>
>> --
>> *Ioannis Canellos*
>> *
>> FuseSource <http://fusesource.com>
>>
>> **
>> Blog: http://iocanel.blogspot.com
>> **
>> Twitter: iocanel
>> *
>>
--
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
Committer & Project Lead
OPS4J Pax for Vaadin
<http://team.ops4j.org/wiki/display/PAXVAADIN/Home> Commiter & Project
Lead
blog <http://notizblog.nierbeck.de/>
Re: [PROPOSAL] Do not depend to OSGi Compendium
Posted by Andreas Pieber <an...@gmail.com>.
>From my side too + 1 to both proposals.
I don't think that the additional version ranges will produce too much work
IIF we're able to keep those versions together in the form of properties.
E. G.
Pax. Web. Version...
Pax. Web. Range...
That way we'll always be reminded if we update one. In addition I think we
can introduce them on demand and don't have to do it all at once.
Kind regards, Andreas
On Jun 4, 2012 11:47 AM, "Ioannis Canellos" <io...@gmail.com> wrote:
> I think that it does make sense without add too much effort.
>
> --
> *Ioannis Canellos*
> *
> FuseSource <http://fusesource.com>
>
> **
> Blog: http://iocanel.blogspot.com
> **
> Twitter: iocanel
> *
>
Re: [PROPOSAL] Do not depend to OSGi Compendium
Posted by Ioannis Canellos <io...@gmail.com>.
I think that it does make sense without add too much effort.
--
*Ioannis Canellos*
*
FuseSource <http://fusesource.com>
**
Blog: http://iocanel.blogspot.com
**
Twitter: iocanel
*
Re: [PROPOSAL] Do not depend to OSGi Compendium
Posted by Guillaume Nodet <gn...@gmail.com>.
If we are to define manual version ranges, we need to do that
centralized in the root pom, at the same location where dependencies
versions are defined.
On Mon, Jun 4, 2012 at 10:41 AM, Christian Schneider
<ch...@die-schneider.net> wrote:
> Some time ago I would have said to let the bundle plugin do its thing
> automatically. The aries 1.0.0 problem shows that this is not possible in
> all cases.
> The minimum version problem like described in the original mail is another
> issue.
>
> So I am +0.5 for having special settings. My main concern is that it is a
> lot of manual work and we might easily do it wrong on occasion. Still the
> advantages top this.
>
> Christian
>
> Am 04.06.2012 10:33, schrieb Achim Nierbeck:
>
>> +1 for the initial question regarding compendium.
>> +1 for defining the version range when using the maven plugin. Even if
>> this troubles some that it doesn't work with the "out-of-the-box way"
>> it's much cleaner if we define the valid version ranges.
>>
>> regards, Achim
>>
>>
>
> --
> 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
Re: [PROPOSAL] Do not depend to OSGi Compendium
Posted by Christian Schneider <ch...@die-schneider.net>.
Some time ago I would have said to let the bundle plugin do its thing
automatically. The aries 1.0.0 problem shows that this is not possible
in all cases.
The minimum version problem like described in the original mail is
another issue.
So I am +0.5 for having special settings. My main concern is that it is
a lot of manual work and we might easily do it wrong on occasion. Still
the advantages top this.
Christian
Am 04.06.2012 10:33, schrieb Achim Nierbeck:
> +1 for the initial question regarding compendium.
> +1 for defining the version range when using the maven plugin. Even if
> this troubles some that it doesn't work with the "out-of-the-box way"
> it's much cleaner if we define the valid version ranges.
>
> regards, Achim
>
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
Re: [PROPOSAL] Do not depend to OSGi Compendium
Posted by Achim Nierbeck <bc...@googlemail.com>.
+1 for the initial question regarding compendium.
+1 for defining the version range when using the maven plugin. Even if
this troubles some that it doesn't work with the "out-of-the-box way"
it's much cleaner if we define the valid version ranges.
regards, Achim
2012/6/4 Jean-Baptiste Onofré <jb...@nanthrax.net>:
> IMHO, I think that the version ranges should be explicitly defined in order
> to control the "backward" compatibility.
>
> Regards
> JB
>
>
> On 06/04/2012 09:55 AM, Guillaume Nodet wrote:
>>
>> +1
>>
>> However, it anyhow raises a different question, which is related to
>> how we manage the ranges.
>> The problem is that the maven plugin computes the range up to the next
>> major version, which means each time we upgrade a dependency, we can't
>> use an older one anymore, even if it would work. That would be an
>> extra work to do however, as we'd have to split the maven dependencies
>> from the lower version of the dependencies we can work with.
>>
>> On Mon, Jun 4, 2012 at 9:43 AM, Jean-Baptiste Onofré<jb...@nanthrax.net>
>> wrote:
>>>
>>> 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
>>>
>>> WDYT ?
>>>
>>> Thanks
>>> Regards
>>> JB
>>> --
>>> Jean-Baptiste Onofré
>>> jbonofre@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>
>>
>>
>>
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
--
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
Committer & Project Lead
OPS4J Pax for Vaadin
<http://team.ops4j.org/wiki/display/PAXVAADIN/Home> Commiter & Project
Lead
blog <http://notizblog.nierbeck.de/>
Re: [PROPOSAL] Do not depend to OSGi Compendium
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
IMHO, I think that the version ranges should be explicitly defined in
order to control the "backward" compatibility.
Regards
JB
On 06/04/2012 09:55 AM, Guillaume Nodet wrote:
> +1
>
> However, it anyhow raises a different question, which is related to
> how we manage the ranges.
> The problem is that the maven plugin computes the range up to the next
> major version, which means each time we upgrade a dependency, we can't
> use an older one anymore, even if it would work. That would be an
> extra work to do however, as we'd have to split the maven dependencies
> from the lower version of the dependencies we can work with.
>
> On Mon, Jun 4, 2012 at 9:43 AM, Jean-Baptiste Onofré<jb...@nanthrax.net> wrote:
>> 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
>>
>> WDYT ?
>>
>> Thanks
>> Regards
>> JB
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>
>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: [PROPOSAL] Do not depend to OSGi Compendium
Posted by Guillaume Nodet <gn...@gmail.com>.
+1
However, it anyhow raises a different question, which is related to
how we manage the ranges.
The problem is that the maven plugin computes the range up to the next
major version, which means each time we upgrade a dependency, we can't
use an older one anymore, even if it would work. That would be an
extra work to do however, as we'd have to split the maven dependencies
from the lower version of the dependencies we can work with.
On Mon, Jun 4, 2012 at 9:43 AM, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> 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
>
> WDYT ?
>
> Thanks
> Regards
> JB
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
--
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
FuseSource, Integration everywhere
http://fusesource.com