David: good ideas, thank you; let me think.
Andrei -------- Original Message -------- Subject: Re: karaf-maven-plugin : aggregateFeatures from inputFile From: David Jencks <[email protected]> To: [email protected] 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 <[email protected]> >> To: [email protected] >> 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 >>>> >>> >> >
