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.
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. 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. 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. 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é > [email protected] > http://blog.nanthrax.net > Talend - http://www.talend.com
