Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 62260

Summary: Double Init of eclipse required to load a new revision of plugin
Product: [Eclipse Project] Equinox Reporter: Emmanuel Wurth <WURTHEMM>
Component: IncubatorAssignee: Thomas Watson <tjwatson>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: P3    
Version: 3.0   
Target Milestone: 3.0 M9   
Hardware: PC   
OS: Windows XP   
Whiteboard:

Description Emmanuel Wurth CLA 2004-05-14 09:13:22 EDT 
I have to shut down and run eclipse two times to have a new revision of a 
plugin loaded.

Version: 3.0.0
Build id: 200405111600

Example: 
Previous is 1.0.0
New one is 1.1.0

One run with 1.0.0 is ok, then shut down.
Copy of 1.1.0 into the plugin dir.
First run after this is the 1.0.0 which is resolved.
Shut down and re run.
This is then the 1.1.0 loaded.

Log:

!SESSION mai 14, 2004 13:46:17.566 ---------------------------------------------
eclipse.buildId=unknown
java.version=1.4.2_03
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=fr_FR
!ENTRY org.eclipse.osgi mai 14, 2004 13:46:17.566
!MESSAGE Bundle 
update@/c:/M9/ANOTHERM9/eclipse/plugins/com.ibm.r2a.rules.rdj_1.1.1/ [105] was 
not resolved.
!SUBENTRY 1 org.eclipse.osgi mai 14, 2004 13:46:17.566
!MESSAGE Bundle 
update@/c:/M9/ANOTHERM9/eclipse/plugins/com.ibm.r2a.rules.rdj_1.1.1/ was picked 
instead.


IN FACT THIS IS THE 1.0.0 which is picked.


!SESSION mai 14, 2004 13:46:43.183 ---------------------------------------------
eclipse.buildId=unknown
java.version=1.4.2_03
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=fr_FR
!ENTRY org.eclipse.osgi mai 14, 2004 13:46:43.183
!MESSAGE Bundle 
update@/c:/M9/ANOTHERM9/eclipse/plugins/com.ibm.r2a.rules.rdj_1.0.0/ [101] was 
not resolved.
!SUBENTRY 1 org.eclipse.osgi mai 14, 2004 13:46:43.183
!MESSAGE Bundle 
update@/c:/M9/ANOTHERM9/eclipse/plugins/com.ibm.r2a.rules.rdj_1.1.1/ was picked 
instead.
Comment 1 Jeff McAffer CLA 2004-05-14 09:27:03 EDT 
suspect this is an update issue.
Comment 2 Dorian Birsan CLA 2004-05-17 12:34:51 EDT 
Jeff, this looks like a runtime issue:

Because the old plugin (1.0.0) is not removed after manually installing the 
newer version (1.0.1), update configurator will just detect the new plugin, 
install it and call refreshPackages().
The expected behavior is that the runtime will now manage various plugin 
version as needed (allowing multiple versions when plugins are only 
contributing libraries, etc.).
The interesting thing is that the runtime does just that, but on the second 
invocation only, when update configurator is not even involved (because that 
invocation runs with cached bundles).
Comment 3 Thomas Watson CLA 2004-05-17 16:36:34 EDT 
The problem here is that refreshPackages will only refresh the bundles that 
are passed, plus any other bundles that depend on the bundles passed.  In this 
case update.configurator is installing the new version of the bundle and 
passing that bundle to be refreshed.  No other bundles depend on this bundle 
so it is the only bundle refreshed.  Since another version of the bundle is 
installed and resolved in the system the Framework will not allow the new 
bundle to be resolved unless the old version of the bundle is refreshed as 
well.

Jeff, we had discussed adding bundles with the same symbolic name to the graph 
of bundles to be refreshed if one of the bundles in the graph is a singleton 
bundle.  This would take care of this situation because when 
update.configurator installs/refreshes version 1.1.0 of the rdj bundle then 
version 1.0.0 of the rdj bundle would also get pulled into the graph of 
bundles to be refreshed.  This would force the correct version of the bundle 
to be picked after the initial call to refresh.  As we discussed this may 
limit the control a management agent has over the set of bundles that is 
refreshed, but this would not be a violation of the OSGi spec since it states 
that an acceptable implementation of refreshPackages is to restart the 
Framework (which is a bit more drastic!!)
Comment 4 Thomas Watson CLA 2004-05-17 16:51:26 EDT 
Will try to get the suggested fix in for M9.
Comment 5 Thomas Watson CLA 2004-05-17 18:06:14 EDT 
Fix is in HEAD.