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. > I think it's great the way it is right now - it's sufficient for this use case and if people need more for provisioning there are other solutions available.
Carsten -- Carsten Ziegeler [email protected]
