On Aug 5, 2009, at 21:37 , Richard S. Hall wrote:
On 8/5/09 14:23, Marcel Offermans wrote:
On Aug 5, 2009, at 18:05 , Richard S. Hall wrote:
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.
If you want to create a replacement for felix.auto.start then why
not have some very simple form of wildcard support in that property
value, so I can just write:
felix.auto.start=file:bundle/*.jar
Yes, I guess this is a variant of the same thing.
I've changed my mind again. This can only really work for "file:"
url's, so it's probably a bad idea after all.
I would not want automatic update or uninstall in any case. If you
want that, use a management agent that is bootstrapped as a bundle.
Keep the launcher as simple as possible.
As I state in another response, I completely agree that uninstall
does not make sense, but update is another story. If I am debugging
a bundle and I start the framework like this:
java -jar bin/felix.jar -b /path/to/bundles
Then it is convenient to not have to do an extra step to update the
bundle that I have changed...and this is very simple to do, it only
added about 5 or 10 lines to the launcher.
Ok, update does not get in the way of some other "management agent" so
if you make that a switch (so I don't have a longer startup time
because the framework is updating all bundles on every launch) then
that's fine!
Greetings, Marcel