Hi,

This this expected behavior per OSGi spec, you need refresh bundle DEF to ensure the changes take effect.

Here is how it works under the hood.

If the snapshot bundle you're updating still used(such as import package) by other bundles. Let's say the snapshot bundle is bundle A, and another bundle B import package from Bundle A. So the scenario is that

Before you update Bundle A, in OSGi container

Bundle A in Revision1<============Bundle B in Revision1

After you update Bundle A, in OSGi container

Bundle A in Revision1<============Bundle B in Revision1 and there's also a Bundle A in Revision2(so here in the OSGi container two revisions for BundleA, but only  Revision1 take effect)

at this moment Bundle B in Revision1 still refer the Bundle A in Revision1, you need explicitly refresh Bundle A which in turn will cause all other bundles use(and transitively use) Bundle A to re-resolve(this operation is really heavy loaded work as so many bundles might be resolved again, it depend on if BundleA play a very basic bundle role), after that the new revision2 for BundleA take effect.

So after you refresh BundleA, in OSGi container,

Bundle A in Revision2<============Bundle B in Revision1

At this moment you changes for that snapshot BundleA take effect.

This kind of two-steps update/refresh operation avoid unnecessarily frequently resolving lots of bundles(as it's cpu consuming task), you can updated several bundles and then refresh  once to get all changes take effect as one goal, and this behavior is totally from OSGi spec.

The different scenario is that if the SNAPSHOT Bundle A is self-used, no other Bundles import package or OSGi service from Bundle A, then update BundleA means the new revision will take effect immediately.

Hope this helps

Freeman