Hi Lidia,
Now, about your case, it seems like you're facing an issue that none of current active developers on p2 has deep knowledge nor need about. So we cannot easily provide more help that you're providing yourself by looking at the code and debugging. Your process (debugging) is the best thing to do at this point, and you'll eventually manage to find the root cause with it - if you did not already. Maybe the root cause is a simple setting to switch, maybe it's a bug in p2... You'll tell us ;)
I couldn't resist looking at it:
As you already noticed, this message comes from InstallOperation.computeProfileChangeRequest which checks whether profile.getInstallableUnitProperty(installedIU, IProfile.PROP_PROFILE_LOCKED_IU) defines the LOCK_UPDATE.
Looking at the only references to PROP_PROFILE_LOCKED_IU where this is set, I see only SurrogateProfileHandle.addSharedProfileBaseIUs sets this property. So it seems like at the moment, p2 simply doesn't allow updates for artifacts in shared profiles and this is a missing feature. It's basically hardcoded to work that way (reject updates on shared install bundles).
If you agree with this analysis, you can open a bug as an enhancement request asking for this to be relaxed.
But I think it's a bit unclear what would be the expectation and the use-case here: if you want the user to get full control on the profile/application, including core updates, what is the value of a shared installation then? Wouldn't it be much simpler to let users have their own copy? And if you really want to stick to shared install, what should the result of an upgrade of the shared install content be? If the goal here is mostly and only to share some jar files and save space, then instead of using a shared installation, you may be interested in looking at Bundle Pooling
https://wiki.eclipse.org/Equinox/p2/Getting_Started#Bundle_pooling
Hope this helps
Mickael
