On Mar 23, 2008, at 5:06 , Tim Moloney wrote:
Richard S. Hall wrote:
Short answer, no. At least not in the sense of truly "disabling the
bundle cache", because the mere fact that you want Felix to
remember that there are bundles in the cache to re-get means that
it must be saving something.
I may be missing something fundamental in how Felix works, but the
point is that I *don't* want Felix to remember that there are
bundles in the cache. During development, I don't want a cache at
all. I can't tell you the number of times I've forgotten to delete
the cache so I wasn't running the code I thought I was.
Persistency of bundles and their state is mandated by the OSGi
specification, so it's behaviour you will see in all frameworks.
For development, you can do a couple of things:
a) Don't even stop your framework, but simply use the shell or a
simple "management agent" bundle, such as the recently donated
FileInstall bundle, to update changed bundles. This model stays much
closer to the final deployment scenario and will occasionally catch
other issues in your code that you would never find when always
starting without a cache.
b) Simply delete your cache as part of your Felix startup script. For
development, I usually define a cache that is in a direct subdirectory
of where I install my framework and bundles, so simply deleting that
directory before startup works fine.
c) Use the option Richard recommended, although I would advise a lot
of caution here, because installing by reference and updating that
reference directly circumvents the OSGi life cycle model and might
lead to all kinds of side effects. I really would recommend using that
option only if you absolutely need the (slight) speedup it gives, not
for serious development or testing.
Greetings, Marcel
