You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@karaf.apache.org by Andrei Pozolotin <an...@gmail.com> on 2012/02/15 00:15:17 UTC
karaf-maven-plugin : aggregateFeatures from inputFile
*David*
1) I noticed you introduced aggregateFeatures
http://karaf.922171.n3.nabble.com/features-plugin-features-td2662909.html
thank you;
2) it seems that it will aggregate only features that come from pom
dependencies;
and if feature comes from inputFIle then aggregate does not work;
3) in my case, pom has no dependencies;
instead I have bunch of repositories and nested features defined in
the inputFile;
can you please let me know how can I produce totally flat resulting
feature.xml in this case;
that is, a features file, which contains a single feature, which
contains only bundles from all transitive dependencies?
(no nested features, no repositories)
Thank you,
Andrei
Re: About karaf upgrade
Posted by Andreas Pieber <an...@gmail.com>.
Hey Xilian,
I'm really sorry to say this, but I don't think that there will be an easy
way to do a delta-update without an explicit Karaf Feature doing this (hey,
btw, wouldn't this be an idea for gsoc?). Such a feature could extract the
current state of the system, download the new version, starts an external
script, replaces/deletes the old files, applies the "old" state, and starts
up again. This might be even kind of OK if we can always ask a user
what/how he wants to do some merges. For now you don't have many options...
Basically you should always start with a new karaf instance only porting
the old one to the new one...
for your point 3.: use a tool like kompare or winmerge to find out how the
folders had been changed and apply the correct parts
for your point 2.: simple copy the deploy folder
for your point 1.: only solution which jumps into my mind here is: convince
your customers to write rather karaf scripts instead of direct karaf
commands. That way you can simply patch-apply the install/start logic on a
new server from those scripts. Not perfect, but till the -p option for
*:install I don't really see another option.
Kind regards,
Andreas
On Tue, Feb 21, 2012 at 09:44, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> Hi Xilai,
>
> we planned to add a -p (persistent) option to bundle:install,
> feature:install, kar:install, etc, in order to store the feature/bundle in
> the system folder in addition of the data folder.
>
> It's planned for Karaf 3.0.
>
> Regards
> JB
>
>
> On 02/21/2012 09:24 AM, XiLai Dai wrote:
>
>> Hi, Andreas,
>>
>> Thanks for you reply! Actually , we want to cover all the artifacts
>> installation behavior from customer:
>>
>> 1.features/bundles which installed from console command;
>>
>> 2.kar (or bundle) files which deployed into deploy/
>>
>> 3.configuration files (new added or modified ) in etc/
>>
>>
>> we want to do a delta update to upgrade the old karaf container, keeping
>> all of already installed features/bundles/kar/config files be there and
>> ready to work.
>>
>> Now the main problem is : How to recognize/reserve the customer
>> installed artifacts in the data/ ? which means only clear the karaf
>> system level artifacts from data/ .
>>
>> Thanks.
>>
>> Xilai
>>
>> *From:*Andreas Pieber [mailto:anpieber@gmail.com]
>> *Sent:* Thursday, February 16, 2012 5:03 PM
>> *To:* user@karaf.apache.org
>> *Subject:* Re: About karaf upgrade
>>
>>
>> OK, currently there is nothing available. And it's also quite dangerous
>> to do so. I think the better approach would be to create your own
>> distribution, upgrade there and produce a completely new rollout package.
>>
>> Still, of cause you can do as you like and it heavily depends on what
>> you do. E.g. how do you deploy your artifacts? Do you have a kar
>> package? Do you install those files one after the other? What you can do
>> depends heavily on your setup. Basically, assume that you change nothing
>> to the original karaf files the following procedure should do:
>>
>> a) stop karaf
>> b) extract the new karaf version
>> c) merge the old system & deploy dir into the new one
>> d) remove the old karaf dir
>> e) move the new one to the place where the old had been.
>>
>> Though, pls keep in mind that all bundles you've started with "start ID"
>> wont start up automatically again (because you've deleted the data dir).
>> Only bundles in the deploy dir will be started again. But tbh I don't
>> know what exactly you would win by this approach.
>>
>> Maybe you can describe how you're using Karaf (and what you modify in
>> the distribution for your setup) a little bin in more detail?
>>
>> Kind regards,
>> Andreas
>>
>> On 02/16/2012 08:39 AM, XiLai Dai wrote:
>>
>> Hello,
>>
>> Just a question from user/production point of view, what is a better way
>> to get karaf container upgrade to a new version with all of the
>> features/bundles/config files existing in the old version karaf
>> container? E.g. from karaf 2.2.2 -> karaf 2.2.5. it’s really boring to
>> redeploy these user artifacts again manually L, are there some approach
>> or tools/scripts or something else can make this process more
>> “automatically”? or is it possible to have a script to upgrade existing
>> karaf container which replace the system artifacts which within the
>> lib/, system/ directory to the new version artifacts? Thanks!
>>
>> Regard
>>
>> Xilai
>>
>>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
Re: About karaf upgrade
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Xilai,
we planned to add a -p (persistent) option to bundle:install,
feature:install, kar:install, etc, in order to store the feature/bundle
in the system folder in addition of the data folder.
It's planned for Karaf 3.0.
Regards
JB
On 02/21/2012 09:24 AM, XiLai Dai wrote:
> Hi, Andreas,
>
> Thanks for you reply! Actually , we want to cover all the artifacts
> installation behavior from customer:
>
> 1.features/bundles which installed from console command;
>
> 2.kar (or bundle) files which deployed into deploy/
>
> 3.configuration files (new added or modified ) in etc/
>
> we want to do a delta update to upgrade the old karaf container, keeping
> all of already installed features/bundles/kar/config files be there and
> ready to work.
>
> Now the main problem is : How to recognize/reserve the customer
> installed artifacts in the data/ ? which means only clear the karaf
> system level artifacts from data/ .
>
> Thanks.
>
> Xilai
>
> *From:*Andreas Pieber [mailto:anpieber@gmail.com]
> *Sent:* Thursday, February 16, 2012 5:03 PM
> *To:* user@karaf.apache.org
> *Subject:* Re: About karaf upgrade
>
> OK, currently there is nothing available. And it's also quite dangerous
> to do so. I think the better approach would be to create your own
> distribution, upgrade there and produce a completely new rollout package.
>
> Still, of cause you can do as you like and it heavily depends on what
> you do. E.g. how do you deploy your artifacts? Do you have a kar
> package? Do you install those files one after the other? What you can do
> depends heavily on your setup. Basically, assume that you change nothing
> to the original karaf files the following procedure should do:
>
> a) stop karaf
> b) extract the new karaf version
> c) merge the old system & deploy dir into the new one
> d) remove the old karaf dir
> e) move the new one to the place where the old had been.
>
> Though, pls keep in mind that all bundles you've started with "start ID"
> wont start up automatically again (because you've deleted the data dir).
> Only bundles in the deploy dir will be started again. But tbh I don't
> know what exactly you would win by this approach.
>
> Maybe you can describe how you're using Karaf (and what you modify in
> the distribution for your setup) a little bin in more detail?
>
> Kind regards,
> Andreas
>
> On 02/16/2012 08:39 AM, XiLai Dai wrote:
>
> Hello,
>
> Just a question from user/production point of view, what is a better way
> to get karaf container upgrade to a new version with all of the
> features/bundles/config files existing in the old version karaf
> container? E.g. from karaf 2.2.2 -> karaf 2.2.5. it’s really boring to
> redeploy these user artifacts again manually L, are there some approach
> or tools/scripts or something else can make this process more
> “automatically”? or is it possible to have a script to upgrade existing
> karaf container which replace the system artifacts which within the
> lib/, system/ directory to the new version artifacts? Thanks!
>
> Regard
>
> Xilai
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
RE: About karaf upgrade
Posted by XiLai Dai <xl...@talend.com>.
Hi, Andreas,
Thanks for you reply! Actually , we want to cover all the artifacts installation behavior from customer:
1. features/bundles which installed from console command;
2. kar (or bundle) files which deployed into deploy/
3. configuration files (new added or modified ) in etc/
we want to do a delta update to upgrade the old karaf container, keeping all of already installed features/bundles/kar/config files be there and ready to work.
Now the main problem is : How to recognize/reserve the customer installed artifacts in the data/ ? which means only clear the karaf system level artifacts from data/ .
Thanks.
Xilai
From: Andreas Pieber [mailto:anpieber@gmail.com]
Sent: Thursday, February 16, 2012 5:03 PM
To: user@karaf.apache.org
Subject: Re: About karaf upgrade
OK, currently there is nothing available. And it's also quite dangerous to do so. I think the better approach would be to create your own distribution, upgrade there and produce a completely new rollout package.
Still, of cause you can do as you like and it heavily depends on what you do. E.g. how do you deploy your artifacts? Do you have a kar package? Do you install those files one after the other? What you can do depends heavily on your setup. Basically, assume that you change nothing to the original karaf files the following procedure should do:
a) stop karaf
b) extract the new karaf version
c) merge the old system & deploy dir into the new one
d) remove the old karaf dir
e) move the new one to the place where the old had been.
Though, pls keep in mind that all bundles you've started with "start ID" wont start up automatically again (because you've deleted the data dir). Only bundles in the deploy dir will be started again. But tbh I don't know what exactly you would win by this approach.
Maybe you can describe how you're using Karaf (and what you modify in the distribution for your setup) a little bin in more detail?
Kind regards,
Andreas
On 02/16/2012 08:39 AM, XiLai Dai wrote:
Hello,
Just a question from user/production point of view, what is a better way to get karaf container upgrade to a new version with all of the features/bundles/config files existing in the old version karaf container? E.g. from karaf 2.2.2 -> karaf 2.2.5. it's really boring to redeploy these user artifacts again manually :(, are there some approach or tools/scripts or something else can make this process more "automatically"? or is it possible to have a script to upgrade existing karaf container which replace the system artifacts which within the lib/, system/ directory to the new version artifacts? Thanks!
Regard
Xilai
Re: About karaf upgrade
Posted by Andreas Pieber <an...@gmail.com>.
OK, currently there is nothing available. And it's also quite dangerous
to do so. I think the better approach would be to create your own
distribution, upgrade there and produce a completely new rollout package.
Still, of cause you can do as you like and it heavily depends on what
you do. E.g. how do you deploy your artifacts? Do you have a kar
package? Do you install those files one after the other? What you can do
depends heavily on your setup. Basically, assume that you change nothing
to the original karaf files the following procedure should do:
a) stop karaf
b) extract the new karaf version
c) merge the old system & deploy dir into the new one
d) remove the old karaf dir
e) move the new one to the place where the old had been.
Though, pls keep in mind that all bundles you've started with "start ID"
wont start up automatically again (because you've deleted the data dir).
Only bundles in the deploy dir will be started again. But tbh I don't
know what exactly you would win by this approach.
Maybe you can describe how you're using Karaf (and what you modify in
the distribution for your setup) a little bin in more detail?
Kind regards,
Andreas
On 02/16/2012 08:39 AM, XiLai Dai wrote:
>
> Hello,
>
> Just a question from user/production point of view, what is a better
> way to get karaf container upgrade to a new version with all of the
> features/bundles/config files existing in the old version karaf
> container? E.g. from karaf 2.2.2 -> karaf 2.2.5. it's really boring
> to redeploy these user artifacts again manually L, are there some
> approach or tools/scripts or something else can make this process more
> "automatically"? or is it possible to have a script to upgrade
> existing karaf container which replace the system artifacts which
> within the lib/, system/ directory to the new version artifacts? Thanks!
>
> Regard
>
> Xilai
>
Re: About karaf upgrade
Posted by "Jamie G." <ja...@gmail.com>.
When making this update document we should also include roll back
instructions/procedure (2.2.5 -> 2.2.2).
Cheers,
Jamie
On Thu, Feb 16, 2012 at 6:35 AM, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> Hi Xilai,
>
> Removing the data folder, and upgrading/merging etc, system, lib should do
> the stuff.
>
> I raised a Jira to document an update process.
>
> More over, thanks to profiles, it should be easy to apply a profile a new
> Karaf instance (whatever the version is).
>
> Regards
> JB
>
>
> On 02/16/2012 08:39 AM, XiLai Dai wrote:
>>
>> Hello,
>>
>> Just a question from user/production point of view, what is a better way
>> to get karaf container upgrade to a new version with all of the
>> features/bundles/config files existing in the old version karaf
>> container? E.g. from karaf 2.2.2 -> karaf 2.2.5. it’s really boring to
>> redeploy these user artifacts again manually L, are there some approach
>> or tools/scripts or something else can make this process more
>> “automatically”? or is it possible to have a script to upgrade existing
>> karaf container which replace the system artifacts which within the
>> lib/, system/ directory to the new version artifacts? Thanks!
>>
>> Regard
>>
>> Xilai
>>
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
Re: About karaf upgrade
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Xilai,
Removing the data folder, and upgrading/merging etc, system, lib should
do the stuff.
I raised a Jira to document an update process.
More over, thanks to profiles, it should be easy to apply a profile a
new Karaf instance (whatever the version is).
Regards
JB
On 02/16/2012 08:39 AM, XiLai Dai wrote:
> Hello,
>
> Just a question from user/production point of view, what is a better way
> to get karaf container upgrade to a new version with all of the
> features/bundles/config files existing in the old version karaf
> container? E.g. from karaf 2.2.2 -> karaf 2.2.5. it’s really boring to
> redeploy these user artifacts again manually L, are there some approach
> or tools/scripts or something else can make this process more
> “automatically”? or is it possible to have a script to upgrade existing
> karaf container which replace the system artifacts which within the
> lib/, system/ directory to the new version artifacts? Thanks!
>
> Regard
>
> Xilai
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: About karaf upgrade
Posted by Willem <wi...@gmail.com>.
Hi,
I think it could be connivence if you just copy the configure from karat 2.2.2 to karat 2.2.5.
It is not a good practice to override the lib and system directory directly, and you also need to clean up the data directory first.
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Weibo: willemjiang
On Feb 16, 2012, at 3:39 PM, XiLai Dai wrote:
> Hello,
>
> Just a question from user/production point of view, what is a better way to get karaf container upgrade to a new version with all of the features/bundles/config files existing in the old version karaf container? E.g. from karaf 2.2.2 -> karaf 2.2.5. it’s really boring to redeploy these user artifacts again manually L, are there some approach or tools/scripts or something else can make this process more “automatically”? or is it possible to have a script to upgrade existing karaf container which replace the system artifacts which within the lib/, system/ directory to the new version artifacts? Thanks!
>
> Regard
> Xilai
About karaf upgrade
Posted by XiLai Dai <xl...@talend.com>.
Hello,
Just a question from user/production point of view, what is a better way to get karaf container upgrade to a new version with all of the features/bundles/config files existing in the old version karaf container? E.g. from karaf 2.2.2 -> karaf 2.2.5. it's really boring to redeploy these user artifacts again manually :(, are there some approach or tools/scripts or something else can make this process more "automatically"? or is it possible to have a script to upgrade existing karaf container which replace the system artifacts which within the lib/, system/ directory to the new version artifacts? Thanks!
Regard
Xilai
Re: karaf-maven-plugin : aggregateFeatures from inputFile
Posted by Andrei Pozolotin <an...@gmail.com>.
David:
good ideas, thank you; let me think.
Andrei
-------- Original Message --------
Subject: Re: karaf-maven-plugin : aggregateFeatures from inputFile
From: David Jencks <da...@yahoo.com>
To: user@karaf.apache.org
Date: Wed 15 Feb 2012 12:43:20 AM CST
> Hi Andrei,
>
> On Feb 14, 2012, at 5:55 PM, Andrei Pozolotin wrote:
>
>> David:
>>
>> -------- Original Message --------
>> Subject: Re: karaf-maven-plugin : aggregateFeatures from inputFile
>> From: David Jencks <da...@yahoo.com>
>> To: user@karaf.apache.org
>> Date: Tue 14 Feb 2012 05:50:29 PM CST
>>> Hi Andrei,
>>>
>>> Aggregating features wouldn't work that way anyway. What it does is
>>> copy all the features in dependencies that are feature repos and
>>> include them as features in the generated feature repo. To get the
>>> feature and feature repository you want I think you would need to
>>> include enough of the bundles as pom dependencies so that all the
>>> desired bundles are transitive dependencies of the included
>>> dependencies.
>> got it;
>>
>> will you accept a new mojo for this function in karaf-maven-plugin
>> if I submit it?
>
> It doesn't seem useful enough to me to include, but I'm not the only
> one here, and maybe I'll change my mind.
>>
>>>
>>> I don't understand why you would want to do what I think you are
>>> suggesting.
>>
>> my motivation is:
>>
>> I have memory constrained environment which needs stripped down
>> minimal karaf setup;
>> I plan to replace full blown karaf "mvn:" protocol resolver bundles
>> with my own tiny one,
>> which will not be able to understand nested features and repositories;
>> hence I need to "render" feature.xml into a "flat bundle list" xml
>> for the run time;
>> I still would like to use plugin for build time, etc.
>
> I don't understand yet. I am somewhat appalled at the size of the
> mvn: url handler, but even if you replace it with something else, all
> it does is interpret mvn: urls. The code that extracts the url from
> the feature xml in the feature repo will be the same. If you are
> going to replace the feature service, why not go a little farther and
> do something more like subsystems or aries ebas and use a manifest
> style list of bundles to install, then you wont need any xml
> processing at all. You might be able to use the aries
> eba-maven-plugin to generate the manifests.
>
> If you don't need to install and uninstall features at runtime you can
> assemble a custom server making all the features you want startup
> features and then you won't even need the feature service at all, all
> bundles will be started from startup.properties.
>
> thanks
> david jencks
>
>>
>>>
>>> thanks
>>> david jencks
>> thank you for getting back :-)
>>
>> Andrei
>>
>>
>>>
>>> On Feb 14, 2012, at 3:15 PM, Andrei Pozolotin wrote:
>>>
>>>> *David*
>>>>
>>>> 1) I noticed you introduced aggregateFeatures
>>>> http://karaf.922171.n3.nabble.com/features-plugin-features-td2662909.html
>>>> thank you;
>>>>
>>>> 2) it seems that it will aggregate only features that come from
>>>> pom dependencies;
>>>> and if feature comes from inputFIle then aggregate does not work;
>>>>
>>>> 3) in my case, pom has no dependencies;
>>>> instead I have bunch of repositories and nested features
>>>> defined in the inputFile;
>>>> can you please let me know how can I produce totally flat
>>>> resulting feature.xml in this case;
>>>> that is, a features file, which contains a single feature,
>>>> which contains only bundles from all transitive dependencies?
>>>> (no nested features, no repositories)
>>>>
>>>> Thank you,
>>>>
>>>> Andrei
>>>>
>>>
>>
>
Re: karaf-maven-plugin : aggregateFeatures from inputFile
Posted by David Jencks <da...@yahoo.com>.
Hi Andrei,
On Feb 14, 2012, at 5:55 PM, Andrei Pozolotin wrote:
> David:
>
> -------- Original Message --------
> Subject: Re: karaf-maven-plugin : aggregateFeatures from inputFile
> From: David Jencks <da...@yahoo.com>
> To: user@karaf.apache.org
> Date: Tue 14 Feb 2012 05:50:29 PM CST
>> Hi Andrei,
>>
>> Aggregating features wouldn't work that way anyway. What it does is copy all the features in dependencies that are feature repos and include them as features in the generated feature repo. To get the feature and feature repository you want I think you would need to include enough of the bundles as pom dependencies so that all the desired bundles are transitive dependencies of the included dependencies.
> got it;
>
> will you accept a new mojo for this function in karaf-maven-plugin if I submit it?
It doesn't seem useful enough to me to include, but I'm not the only one here, and maybe I'll change my mind.
>
>>
>> I don't understand why you would want to do what I think you are suggesting.
>
> my motivation is:
>
> I have memory constrained environment which needs stripped down minimal karaf setup;
> I plan to replace full blown karaf "mvn:" protocol resolver bundles with my own tiny one,
> which will not be able to understand nested features and repositories;
> hence I need to "render" feature.xml into a "flat bundle list" xml for the run time;
> I still would like to use plugin for build time, etc.
I don't understand yet. I am somewhat appalled at the size of the mvn: url handler, but even if you replace it with something else, all it does is interpret mvn: urls. The code that extracts the url from the feature xml in the feature repo will be the same. If you are going to replace the feature service, why not go a little farther and do something more like subsystems or aries ebas and use a manifest style list of bundles to install, then you wont need any xml processing at all. You might be able to use the aries eba-maven-plugin to generate the manifests.
If you don't need to install and uninstall features at runtime you can assemble a custom server making all the features you want startup features and then you won't even need the feature service at all, all bundles will be started from startup.properties.
thanks
david jencks
>
>>
>> thanks
>> david jencks
> thank you for getting back :-)
>
> Andrei
>
>
>>
>> On Feb 14, 2012, at 3:15 PM, Andrei Pozolotin wrote:
>>
>>> David
>>>
>>> 1) I noticed you introduced aggregateFeatures
>>> http://karaf.922171.n3.nabble.com/features-plugin-features-td2662909.html
>>> thank you;
>>>
>>> 2) it seems that it will aggregate only features that come from pom dependencies;
>>> and if feature comes from inputFIle then aggregate does not work;
>>>
>>> 3) in my case, pom has no dependencies;
>>> instead I have bunch of repositories and nested features defined in the inputFile;
>>> can you please let me know how can I produce totally flat resulting feature.xml in this case;
>>> that is, a features file, which contains a single feature, which contains only bundles from all transitive dependencies?
>>> (no nested features, no repositories)
>>>
>>> Thank you,
>>>
>>> Andrei
>>
>
Re: karaf-maven-plugin : aggregateFeatures from inputFile
Posted by Andrei Pozolotin <an...@gmail.com>.
David:
-------- Original Message --------
Subject: Re: karaf-maven-plugin : aggregateFeatures from inputFile
From: David Jencks <da...@yahoo.com>
To: user@karaf.apache.org
Date: Tue 14 Feb 2012 05:50:29 PM CST
> Hi Andrei,
>
> Aggregating features wouldn't work that way anyway. What it does is
> copy all the features in dependencies that are feature repos and
> include them as features in the generated feature repo. To get the
> feature and feature repository you want I think you would need to
> include enough of the bundles as pom dependencies so that all the
> desired bundles are transitive dependencies of the included dependencies.
got it;
will you accept a new mojo for this function in karaf-maven-plugin if I
submit it?
>
> I don't understand why you would want to do what I think you are
> suggesting.
my motivation is:
I have memory constrained environment which needs stripped down minimal
karaf setup;
I plan to replace full blown karaf "mvn:" protocol resolver bundles with
my own tiny one,
which will not be able to understand nested features and repositories;
hence I need to "render" feature.xml into a "flat bundle list" xml for
the run time;
I still would like to use plugin for build time, etc.
>
> thanks
> david jencks
thank you for getting back :-)
Andrei
>
> On Feb 14, 2012, at 3:15 PM, Andrei Pozolotin wrote:
>
>> *David*
>>
>> 1) I noticed you introduced aggregateFeatures
>> http://karaf.922171.n3.nabble.com/features-plugin-features-td2662909.html
>> thank you;
>>
>> 2) it seems that it will aggregate only features that come from
>> pom dependencies;
>> and if feature comes from inputFIle then aggregate does not work;
>>
>> 3) in my case, pom has no dependencies;
>> instead I have bunch of repositories and nested features defined
>> in the inputFile;
>> can you please let me know how can I produce totally flat
>> resulting feature.xml in this case;
>> that is, a features file, which contains a single feature, which
>> contains only bundles from all transitive dependencies?
>> (no nested features, no repositories)
>>
>> Thank you,
>>
>> Andrei
>>
>
Re: karaf-maven-plugin : aggregateFeatures from inputFile
Posted by David Jencks <da...@yahoo.com>.
Hi Andrei,
Aggregating features wouldn't work that way anyway. What it does is copy all the features in dependencies that are feature repos and include them as features in the generated feature repo. To get the feature and feature repository you want I think you would need to include enough of the bundles as pom dependencies so that all the desired bundles are transitive dependencies of the included dependencies.
I don't understand why you would want to do what I think you are suggesting.
thanks
david jencks
On Feb 14, 2012, at 3:15 PM, Andrei Pozolotin wrote:
> David
>
> 1) I noticed you introduced aggregateFeatures
> http://karaf.922171.n3.nabble.com/features-plugin-features-td2662909.html
> thank you;
>
> 2) it seems that it will aggregate only features that come from pom dependencies;
> and if feature comes from inputFIle then aggregate does not work;
>
> 3) in my case, pom has no dependencies;
> instead I have bunch of repositories and nested features defined in the inputFile;
> can you please let me know how can I produce totally flat resulting feature.xml in this case;
> that is, a features file, which contains a single feature, which contains only bundles from all transitive dependencies?
> (no nested features, no repositories)
>
> Thank you,
>
> Andrei