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