Karl Pauls wrote:
What happens when Bundle.update is called, but the new bundle data has a
different Bundle-Version? Does it result in an exception? I would expect it
to, since a Bundle-SymbolicName and Bundle-Version combination uniquely
identifies a bundle instance.

Well, during an update the bundle is first stopped, then updated and
the new version is started. It shouldn't result in an exception if you
update a bundle to a different version number.

4.3.10 Updating Bundles
...
The update process supports migration from one version of a bundle to a
newer version of the same bundle. The exports of an updated bundle must
be immediately available to the Framework. If none of the old exports are
used, then the old exports must be removed. Otherwise, all old exports must
remain available for existing bundles and future resolves until the
refreshPackages method is called or the Framework is restarted.

Kind of confusing. How does a user get the new org.osgi.framework.Bundle object? Bundle.update() returns void and a bundle's BundleId remains same even after update (it's defined that way in the spec). If the old org.osgi.framework.Bundle object now points to the new bundle, how do I get to the bundle with the old Bundle-Version, if at all I need to.
If the spec expects users not to change
Bundle-Version while calling update, then I fail to see how it is used in a
proper version controlled environment.

Where does it say so in the spec?
No, the spec does not say so, nor does it say the opposite. That's why I used "if". I am trying to find out the intention.
My understanding is that Bundle-Version is an implementation version, hence any 
time a user changes
anything in the bundle, be it a manifest update or some bug fix, in a proper
version control environment, the new bundle should have a different
Bundle-Version.

I agree and that should be possible.

Thanks for stating your opinion, and I am glad we agree on this point. I am also interested to know use cases of updating the bundle without updating the Bundle-Version in production environment.

Thanks,
Sahoo
regards,

Karl

Thanks,
Sahoo

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]






---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to