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
