felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: New framework launcher
Date Wed, 05 Aug 2009 20:20:03 GMT
On 8/5/09 16:11, Filippo Diotalevi wrote:
> On Wed, Aug 5, 2009 at 6:05 PM, Richard S. Hall<heavy@ungoverned.org>  wrote:
>    
>> Hey guys,
>>
>> The benefit here is we no longer need to configure the felix.auto.start
>> property to auto deploy the bundles in the "bundle" directory. If you want
>> to add/remove bundles, you just add/remove them to/from the "bundle"
>> directory. This is intended to be much simpler than File Install and only
>> takes effect at framework startup with no monitoring of the directory at run
>> time. (I originally thought about using File Install, but after a spate of
>> threading issues with File Install in JIRA, I felt it was maybe too much.)
>>      
> I think that would be a nice enhancement to the launcher (great for
> experiments and prototyping), as long as it is possible to preserve
> the current behavior (to make to upgrade in existing application
> smooth)
>    

Yes, you can get the existing behavior. I didn't remove anything, just 
changed it to use the new auto-deploy mechanism by default.

>> One issue I was wondering about is whether or not I should make the launcher
>> perform an update on bundles in the "bundle" directory when they are already
>> installed. This would be a change from previous behavior, which always just
>> installed so you would only see the existing installed bundle even if you
>> changed the target. It seems like this could be convenient, but not strictly
>> necessary. What do you think?
>>      
> I'm not sure we need that. Sure it is useful, but it would be just an
> half-baked provisioning system, where you can only update bundles but
> not install or uninstall them.
>    

Well, you can install them, but definitely not install them. See my 
other posts about the benefits of update...as you mention above, it too 
is quite handy for experiments and prototyping.

Ultimately, felix.auto.start/install are a half-baked provisioning 
mechanism. We have to accept that. Here we are just talking about minor 
inprovements to this existing half-backed approach. I have committed the 
the changes in main if you want to see how minor they are and get an 
idea of how it works.

-> richard


Mime
View raw message