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

Bug 335746

Summary: RCP product self-update fails from carbon to cocoa
Product: [Eclipse Project] Equinox Reporter: Kay Kasemir <kasemirk>
Component: p2Assignee: P2 Inbox <equinox.p2-inbox>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: aniefer, pascal
Version: unspecified   
Target Milestone: ---   
Hardware: Macintosh   
OS: Mac OS X - Carbon (unsup.)   
Whiteboard:

Description Kay Kasemir CLA 2011-01-28 18:07:18 EST 
Build Identifier: 20100917-0705

I have an RCP product, created with a headless built for OS X, Linux, Windows.
All is fine with Linux and Windows, the following only applies to OS X.

I used to have this in build.properties:
   configs=macosx, carbon, x86 

Recently switched to this:
   configs=macosx,cocoa,x86

The RCP product still builds and runs OK.

BUT: When using self-update of the previous carbon-based product to the new cocoa-based product, the original myproduct.app is gone after the update. Instead, there is a new and rather empty Eclipse.app folder, and the product doesn't start.

When reverting the build back to carbon, the self-update of an older product works OK.

I assume this is what's happening:
The old product used
org.eclipse.equinox.launcher.carbon.macosx,
org.eclipse.swt.carbon.macosx,
org.eclipse.ui.carbon.

The new product should use the cocoa versions of these plugins.
The self-update gets as far as deleting the old carbon-based launcher, but fails to install the new cocoa based launcher.

Maybe it does that because the old product is running ws=carbon, so it thinks the install of cocoa does not make sense?

I set these debug options before attempting the self-update of a carbon product to cocoa:
org.eclipse.equinox.p2.engine/profileregistry/debug = true
org.eclipse.equinox.p2.engine/engine/debug = true
org.eclipse.equinox.p2.engine/enginesession/debug = true

The debug output includes many lines like these:
  ,toolingorg.eclipse.equinox.launcher.carbon.macosx 1.1.1.R36x_v20100810[] --> null
...
   ,[R]org.eclipse.equinox.launcher.carbon.macosx 1.1.1.R36x_v20100810[toolingorg.eclipse.equinox.launcher.carbon.macosx 1.1.1.R36x_v20100810 ] --> [R]org.eclipse.equinox.launcher.carbon.macosx 1.1.1.R36x_v20100810[tooling.osgi.bundle.default 1.0.0 ]

I assume that means carbon plugins are replaced with the same or nothing.
The isn't a single mention of cocoa in the debug output, so the update process must totally miss the need to install the cocoa plugins.

Where do I look for more information?
Do I need a p2.inf to assert that the new cocoa plugins are installed?
Any help is greatly appreciated!

Reproducible: Always

Steps to Reproduce:
1.Build carbon-based RCP product: OK
2.Update versions, build new product for cocoa: OK
3.Attempt self-update of older product from 1: Empty launcher directory
Comment 1 Andrew Niefer CLA 2011-02-01 15:53:31 EST 
The root of the problem is that a specific install is only for a single platform (carbon)  when you try to update to a version built for cocoa, none of the cocoa specific pieces will install because they don't match the existing install's platform.

The install's platform is specified by the "org.eclipse.equinox.p2.environments" property in the profile files (under 
eclipse/p2/org.eclipse.equinox.p2.engine/profileRegistry/*.profile)

I don't know if it is possible to change profile properties using the p2.inf
Comment 2 Kay Kasemir CLA 2011-02-01 17:40:14 EST 
Thank you very much for your comment!

I have users with installed RCPs that check for updates on startup, and having Mac users end up with a broken product after such a failed carbon-to-cocoa update would of course be bad.

What is my most practical option?

Stick with carbon-based product?

Make key plugins require ws=cocoa, so they will not show up as self-update options? Mac users with the carbon product will have to manually install the new cocoa based product?

Or is it likely that p2.inf would allow changing the org.eclipse.equinox.p2.environments property?
Comment 3 Pascal Rapicault CLA 2011-02-02 10:41:04 EST 
There are basically two options:
1) Prevent the update from carbon-to-cocoa (add a filter on the root IU that prevents it to install on cocoa) and tell your users to download the cocoa version
2) Replace the "search for update" (probably hook a new action and remove the p2 one) by your own search for update. This new search for update would find the new IU, then you would tweak the profile properties to match ws=cocoa, and finally do the installation. 
Of course, since what is currently in the field is running the normal update code,  you will first have to roll out a version to deploy the new update operation, and then make available the cocoa based app.

> Or is it likely that p2.inf would allow changing the org.eclipse.equinox.p2.environments property?
  At this point this is not possible.
Comment 4 Kay Kasemir CLA 2011-02-02 12:17:09 EST 
> add a filter on the root IU that prevents it to install on cocoa
Yes, that is a "works-for-me" solution!

My knowledge of P2 is limited to running the headless build and using the repository.mirrorApplication to add the 'latest' buildRepo to our update site.

I added this to the MANIFEST.MF of the plugin that defines the product:
    Eclipse-PlatformFilter: (| (osgi.ws=win32)(osgi.ws=cocoa)(osgi.ws=gtk))

Is that a good way to do it?

It seems to work OK:
On Linux and I assume also win32 the self-update still works.
On OS X with a carbon product, the popup for self-update on startup no longer appears.
If I manually invoke Help/Check for Updates, an available update is displayed but with an error "The operation cannot be completed..... Cannot satisfy dependency".

It doesn't say why, like "no matching window system", but my prime goal to suppress auto-update from carbon to broken is met.

Thanks!!