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 >> >
