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