You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@karaf.apache.org by Jean-Baptiste Onofré <jb...@nanthrax.net> on 2011/10/28 11:57:37 UTC
[PROPOSAL] Several proposals
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
Re: [PROPOSAL] Several proposals
Posted by Charles Moulliard <cm...@gmail.com>.
Whow Andreas, you are a mathematician (4x+1) ;-)
On Fri, Oct 28, 2011 at 2:48 PM, Andreas Pieber <an...@gmail.com> wrote:
> to make it short: 4x+1
>
> Kind regards,
> Andreas
>
> On Fri, Oct 28, 2011 at 14:45, Ioannis Canellos <io...@gmail.com> wrote:
>
>> Ok, it sounds simple and clean.
>>
>> --
>> *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
>> *
>>
>
Re: [PROPOSAL] Several proposals
Posted by Andreas Pieber <an...@gmail.com>.
to make it short: 4x+1
Kind regards,
Andreas
On Fri, Oct 28, 2011 at 14:45, Ioannis Canellos <io...@gmail.com> wrote:
> Ok, it sounds simple and clean.
>
> --
> *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
> *
>
Re: [PROPOSAL] Several proposals
Posted by Ioannis Canellos <io...@gmail.com>.
Ok, it sounds simple and clean.
--
*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
*
Re: [PROPOSAL] Several proposals
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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<io...@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
Re: [PROPOSAL] Several proposals
Posted by "Jamie G." <ja...@gmail.com>.
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<io...@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
>
Re: [PROPOSAL] Several proposals
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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<io...@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
Re: [PROPOSAL] Several proposals
Posted by Gert Vanthienen <ge...@gmail.com>.
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 <io...@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
> *
>
Re: [PROPOSAL] Several proposals
Posted by Ioannis Canellos <io...@gmail.com>.
*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
*
Re: [PROPOSAL] Several proposals
Posted by Achim Nierbeck <bc...@googlemail.com>.
Hi JB,
1) this is for sure a great improvement cause doing not so just confuses our
users :) +1
2) sounds good to me +1
3) +1 it's lightweight so just include it.
4) +1 I guess this could help us in the future with features
regards, Achim
2011/10/28 Jean-Baptiste Onofré <jb...@nanthrax.net>
> 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
>
--
--
*Achim Nierbeck*
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
blog <http://notizblog.nierbeck.de/>
Re: [PROPOSAL] Several proposals
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Mike,
We HAVE TO implement something similar to subsystems. However subsystems
is part of OSGi 4.3, and so focus on trunk/Karaf 3.0.
I think that we have to address the problem on Karaf 2.2.x (so OSGi r4.2).
I have no problem to have two different approaches: one "subsystems
oriented" for the trunk, one "features oriented" for the 2.2.x branch.
Another solution is to not handle this issue on 2.2.x branch and focus
on trunk.
But it means that we need a bunch of time to stabilize Karaf 3.0.
I wonder if creating a Karaf 2.3 branch could not have sense. It will
give community new releases including new fixes, etc, and give us more
time to stabilize Karaf 3.0.
Regards
JB
On 11/01/2011 04:52 PM, mikevan wrote:
> JB, instead of widening the scope of the features, shouldn't we be focusing
> on implementing something similar to that which is proposed in the OSGi
> Service Platform Subsystems proposed specification?
>
> -----
> Mike Van (All links open in new tabs)
> Committer - Kalumet
>
> Atraxia Technologies
>
> NCI Inc
>
> Mike Van's Open Source Technologies Blog
> --
> View this message in context: http://karaf.922171.n3.nabble.com/PROPOSAL-Several-proposals-tp3460542p3471054.html
> Sent from the Karaf - Dev mailing list archive at Nabble.com.
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: [PROPOSAL] Several proposals
Posted by mikevan <mv...@comcast.net>.
JB, instead of widening the scope of the features, shouldn't we be focusing
on implementing something similar to that which is proposed in the OSGi
Service Platform Subsystems proposed specification?
-----
Mike Van (All links open in new tabs)
Committer - Kalumet
Atraxia Technologies
NCI Inc
Mike Van's Open Source Technologies Blog
--
View this message in context: http://karaf.922171.n3.nabble.com/PROPOSAL-Several-proposals-tp3460542p3471054.html
Sent from the Karaf - Dev mailing list archive at Nabble.com.
Re: [PROPOSAL] Several proposals
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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
Re: [PROPOSAL] Several proposals
Posted by David Jencks <da...@yahoo.com>.
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é
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
Re: [PROPOSAL] Several proposals
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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
Re: [PROPOSAL] Several proposals
Posted by Charles Moulliard <cm...@gmail.com>.
+1 for point 1. This is mandatory and also an incredible feature which
is not well documented and not know by a lot of user <config/> and
<configfile/> except from us and karaf features file for http/war
+1 for point 2 but be carefull as suggested Ioannis
+1 for point 3. That will question users about what is kar, what can
we do with KAR, what is the added value of KAR instead of packaging
everything in a ZIP ;-)
On Fri, Oct 28, 2011 at 11:57 AM, Jean-Baptiste Onofré <jb...@nanthrax.net> 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
>