You've definitely come across the big gap in functionality regarding the Uber packaging. You are right about the deployment admin spec and the bundle ownership issue was one of the issues that kept us from using it. Karaf "features" were created to kind of fill that gap until something more suitable came along, so even what we came up with has limitations.
Spring DM has a packaging scheme, and the Aries project has another variation called Applications: http://incubator.apache.org/aries/applications.html. I think the Aries application concept is the best option for most uses, but I am not sure how far along the implementation is. At one point we had discussed adopting that implementation as a replacement for Features but I'll let Guillaume give his opinion on that. Chris <http://incubator.apache.org/aries/applications.html> -- Chris Custine FUSESource :: http://fusesource.com My Blog :: http://blog.organicelement.com Apache ServiceMix :: http://servicemix.apache.org Apache Felix :: http://felix.apache.org Apache Directory Server :: http://directory.apache.org On Mon, Jul 19, 2010 at 20:26, Mark Derricutt <[email protected]> wrote: > Interesting, I just noticed that with having the <configuration> > blocks inside the feature file, they reset/overwrite any changes made > via the GUI when restarting. So I think I'll go away from sticking > default settings in there. > > I understand where you're coming from with the features being rather > static - I was then wondering what method people are generally using > for deploying applications into their runtimes. OBR? > Deployment-Packages? > > I like the idea of the deployment-package, having a single versioned > .dp file that contains all of our apps bundles for version X which > could be dropped into the ./deploy directory, but I had read somewhere > in the compendium that if you deploy via a deployment-package, then > the individual bundles can only be updated ALSO via a deployment > package ( I've not yet tested this method tho ). > > It seems there's several options all with pros/cons - would be nice to > see a "current best practice" doc... > > Mark > > > -- > Pull me down under... > > On Mon, Jul 19, 2010 at 6:33 PM, Guillaume Nodet <[email protected]> wrote: > > For the configuration, I'm not sure how to handle the changes, as the > > configuration in the feature is mostly an initial configuration but it > > could be changed by users afterward, so I'm kinda tempted to say that > > we would only register new properties and let existing ones as they > > are. >
