Aries Applications are pretty neat and have some great ideas, but currently the 
plan is that each application gets deployed into a separate isolation 
environment of some kind (this part isn't implemented yet).    Unless that idea 
gets changed, they may be great for applications but won't be much use for 
assembling a server.

david jencks

On Jul 19, 2010, at 9:14 PM, Chris Custine wrote:

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

Reply via email to