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

Reply via email to