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 Sat, 29 Oct 2011 10:06:00 GMT
Hi David,

> 1.  I've been watching with increasing concern the attempts to push config admin changes
back into cfg files.  I don't understand why we would want to duplicate config admin persistence.
 I don't understand why we would want to change the behavior of a clean start so dramatically.
 I think all extra uses of .cfg files other than as one possible way of installing an initial
configuration into config admin are a bad idea.  So I think this one is too.  I hope someone
can explain the thinking behind this recent activity.  -1.
We have to leverage the existing. If <configfile/>, config shell 
commands, and MBeans update the cfg files, we should be consistent for 
<config/> tag.
We already planned to use ConfigAdmin persistence on trunk (Karaf 3) by 
using a Config service.

>
> 2. I think this is a really good idea, but I'd prefer it if we could rearrange stuff
after getting trunk up to osgi 4.3.  I've been working off a patch karaf for several months
now waiting for jb to upgrade to 4.3 (I have a local upgrade but id doesn't work with felix
and not all integration tests pass) and I'm worried about losing changes I've made.
Agree. If you take a look on KARAF-855, I submitted a patch to update to 
OSGi 4.3. Guillaume provided another one. I'm gonna merge both to test 
and validate the whole Karaf behavior.

>
> 3. Sure, no problem, I left it out of bootFeatures in the new style assemblies only because
it wasn't there in the old one.  However I think we also need to bring back the "full" feature,
see my -1 of rev 1181815 (oct 24) that removed the full kar.
I'm not sure for the full feature. I think framework and standard 
features are enough.
I don't want to have a lot of distributions.

>
> 4. I'm not too sure about this.  I think the idea of a feature repository is something
we should be moving away from in favor of individual features as artifacts in an obr.
Agree, it's the purpose of Cave. Cave will bring features and KARs 
repository.

Regards
JB

>
> thanks
> david jencks
>
> On Oct 28, 2011, at 3:04 AM, Jean-Baptiste Onofré wrote:
>
>> Another proposal comes from Gert.
>>
>> The purpose is to support "version range" in the<repository/>  tag in a features
descriptor.
>>
>> As we support version range in the feature (for instance<feature version="[2.5,4)">cxf</feature>),
the<repository/>  tag should also support version range.
>>
>> I'm going to raise the corresponding Jira.
>>
>> Regards
>> JB
>>
>> On 10/28/2011 11:57 AM, Jean-Baptiste Onofré wrote:
>>> Hi all,
>>>
>>> I have some proposals to submit to your approval:
>>>
>>> 1. Feature<config/>  tag should be able to create the corresponding etc
>>> file (KARAF-970). If the<configfile/>  tag create the cfg file in the
>>> etc folder (it's the purpose of this tag ;)), the<config/>  tag create
>>> the properties only the properties in the ConfigAdmin memory, it doesn't
>>> flush into the Karaf cfg file. This behavior could be defined by a
>>> property in the etc/org.apache.karaf.features.cfg file.
>>>
>>> 2. Refactoring of the Maven modules on trunk (KARAF-963). For instance,
>>> the config shell commands are in shell/config module, and the config
>>> MBean is in the management/mbeans/config module. More over, we are going
>>> to add new OSGi services (for config, for wrapper, for kar, etc, etc). I
>>> propose to refactore the Maven modules to use a structure similar to
>>> admin or features modules. For instance, it means that we will have a
>>> config module containing a core module (containing the core
>>> implementation and the OSGi services), a command module (containing the
>>> shell commands), a management module (containing the MBeans).
>>>
>>> 3. Include the kar feature by default. To "promote" the usage of the KAR
>>> artifacts, I think it could be interesting to provide the KAR support by
>>> default in Karaf (as a bootFeatures). The KAR deployer is light and
>>> doesn't cause overhead.
>>>
>>> WDYT ?
>>>
>>> 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

Mime
View raw message