karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Baptiste Onofré ...@nanthrax.net>
Subject Re: [PROPOSAL] Several proposals
Date Fri, 28 Oct 2011 12:31:53 GMT
For 2, it's true, the artifacts name will change, etc. But I think it's 
the safest way to start the Karaf 3 branch, avoid code duplication, and 
have a clean structure.

Regards
JB

On 10/28/2011 02:24 PM, Jamie G. wrote:
> Proposal 1: +1
> Proposal 2: +1 (if we're going to do any other major refactors then
> this is the time to do it - as Ioannis mentioned, this may change
> artifact names, etc).
> Proposal 3: +1
> Proposal 4: +1
>
> On Fri, Oct 28, 2011 at 9:48 AM, Jean-Baptiste Onofré<jb@nanthrax.net>  wrote:
>> Agree with Gert's proposal.
>>
>> More than a version range, it's just a check on the URL already registered.
>>
>> The regex checks the URL without the version.
>>
>> I will apply this behavior on karaf-2.2.x branch and trunk.
>>
>> Regards
>> JB
>>
>> On 10/28/2011 02:14 PM, Gert Vanthienen wrote:
>>>
>>> L.S.,
>>>
>>>
>>> My suggestion would be to:
>>> - first look for an installed features url that matches the requirement -
>>> if
>>> that already exists, just go ahead and don't install anything else
>>> - if there's no suitable descriptor yet, let pax url mvn resolve that url,
>>> which should give you the highest available inside the range
>>>
>>> If there's already a non-matching version installed, I would just stick to
>>> the same routine and have it install a second (other version) features
>>> descriptor as well - after all, one of the benefits of using OSGi is to be
>>> able to use multiple versions of the same thing.  I'm not sure how
>>> transitive repository definitions make a difference here, it's actually
>>> there that this feature would be the most useful (at least, from my
>>> perspective in ServiceMix) - if we use cxf and camel and camel use cxf as
>>> well, that's exactly where I would like this solution to make sure that we
>>> don't get duplicate versions installed.
>>>
>>>
>>> Regards,
>>>
>>> Gert Vanthienen
>>> ------------------------
>>> FuseSource
>>> Web: http://fusesource.com
>>> Blog: http://gertvanthienen.blogspot.com/
>>>
>>>
>>> On Fri, Oct 28, 2011 at 1:29 PM, Ioannis Canellos<iocanel@gmail.com>
>>>   wrote:
>>>
>>>> *Feature config attribute:* +1 I consider this really important and is
>>>> something that is currently missing.
>>>> *Refactoring of maven modules: *0. I am not sure of how the end result
>>>> will
>>>> be, so I am not sure? I assume that this will change artifact names etc,
>>>> and
>>>> I am not sure of what the added value will be. I don't object, I just
>>>> would
>>>> like to hear more about the details to make my mind.
>>>> *Making Kar default: *+1.
>>>> *Repository version ranges: *+1. There are a lot of times where I felt
>>>> that
>>>> this was something that was missing. There are a few cases that we need
>>>> to
>>>> cover.
>>>>
>>>> I assume that when we are talking about something like this:
>>>>
>>>>
>>>> <repository>mvn:org.cool.product/cool-product/[2,4)/xml/features</repository>
>>>> *(I will use this as a reference for my questions below)*
>>>>
>>>> a) Which will be the default repository that will be used? I assume
>>>> highest
>>>> version available.
>>>> b) How will we treat cases were ranges are incompatible? Install both
>>>> versions?
>>>> c) How should we handle transitive repositories?
>>>> d) Will we have some functionality that will try to identify the repo
>>>> version to use depending on the artifacts we already have installed?
>>>>
>>>>
>>>> --
>>>> *Ioannis Canellos*
>>>> *
>>>> FuseSource<http://fusesource.com>
>>>>
>>>> **
>>>> Blog: http://iocanel.blogspot.com
>>>> **
>>>> Apache Karaf<http://karaf.apache.org/>    Committer&    PMC
>>>> Apache ServiceMix<http://servicemix.apache.org/>     Committer
>>>> Apache Gora<http://incubator.apache.org/gora/>    Committer
>>>> *
>>>>
>>>
>>
>> --
>> 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

Mime
View raw message