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 19:26:52 GMT
On 8/5/09 13:48, Sahoo wrote:
> If it performs an update for modified bundles, then I expect it to 
> uninstall any missing bundles and install any new bundles during 
> subsequent restart.

If that's the case, then I would rather not do updates at all.

But I don't see why supporting update would require supporting 
uninstall. Certainly that is not how felix.auto.start does behaves. 
However, I think it would make sense for felix.auto.start processing to 
also do updates as well (although currently it doesn't).

There is no way this should do uninstalls, since there are lots of ways 
people might install bundles into their cache (e.g., OBR, manually, 
etc.). We'd be pissing lots of people off if every time they started 
their framework we deleted everything that wasn't in their local bundle 

Again, the goal here is for an enhanced/configuration-less 
felix.auto.start mechanism, not an approximation of File Install.

-> richard

> Thanks,
> Sahoo
> Richard S. Hall wrote:
>> Hey guys,
>> I have changed the framework launching code in Main to try to 
>> eliminate some need for configuration. The idea is to have the 
>> launcher work a little bit like File Install in that it automatically 
>> will install and start any bundles found in the "bundle" directory. 
>> No existing functionality has been removed and for the most part it 
>> should look very similar to the previous behavior.
>> 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.)
>> Currently, the only real noticeable change is that we now use the 
>> absolute path as the location of the installed bundle, rather than a 
>> relative path. This could cause some exceptions for existing caches, 
>> but they will still function. (We had some issues with File Install 
>> and relative URLs previously, so this change will work better with 
>> that in the future I think.)
>> 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 do not think doing an uninstall of missing bundles would be a good 
>> idea, though. The whole point is to provide a simple, 
>> configuration-less way to get bundles into your framework at startup, 
>> i.e., a replacement for felix.auto.start. I don't want to create a 
>> complex provisioning solution...that is a separate project.
>> I'd like to get this wrapped up quickly, so any input is welcome. 
>> Thanks.
>> -> richard

View raw message