Bug 378811 - [Perspectives] Can't export and import perspectives anymore
Summary: [Perspectives] Can't export and import perspectives anymore
Status: VERIFIED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 4.2   Edit
Hardware: PC Windows 7
: P3 normal with 16 votes (vote)
Target Milestone: 4.4.2+   Edit
Assignee: Kalyan Prasad Tatavarthi CLA
QA Contact:
URL:
Whiteboard:
Keywords:
: 385920 386178 391486 (view as bug list)
Depends on: 485106
Blocks: 378644
  Show dependency tree
 
Reported: 2012-05-08 06:27 EDT by Dani Megert CLA
Modified: 2016-05-01 13:53 EDT (History)
34 users (show)

See Also:


Attachments
perspectives3x.epf (30.99 KB, application/octet-stream)
2015-05-03 11:59 EDT, Dani Megert CLA
no flags Details
perspectives4x.epf (30.40 KB, application/octet-stream)
2015-05-03 12:00 EDT, Dani Megert CLA
no flags Details
Attached image shows the API break on the UI (134.29 KB, image/png)
2015-09-22 18:44 EDT, Patrik Suzzi CLA
no flags Details
It seems the problem it's the same (2.46 MB, video/mp4)
2015-09-24 15:41 EDT, Patrik Suzzi CLA
no flags Details
testcase for 3x perspective changes with missing views (18.34 KB, application/octet-stream)
2015-11-03 04:15 EST, Kalyan Prasad Tatavarthi CLA
no flags Details
testcase for 4.x perspective changes with missing views (13.48 KB, application/octet-stream)
2015-11-03 04:16 EST, Kalyan Prasad Tatavarthi CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dani Megert CLA 2012-05-08 06:27:15 EDT
3.8 M7 -> 4.2 M7.

Starting a 3.8 workspace with 4.2 looses all my custom saved perspectives plus all changes saved to the existing perspectives.
Comment 1 Eric Moffatt CLA 2012-05-08 13:02:10 EDT
While this is an issue it has never been reported as a defect until now. There has never been any indication that this will be done and is covered by

http://www.eclipse.org/eclipse/development/readme_eclipse_4.1.html

where it's clearly stated:

"User interface session state may be discarded when a workspace is upgraded."

Dani, how do you migrate this info to new workspaces ?

In 4.3 the intention is to allow the UI Model to exist separately from the workspace, allowing the re-use of the same UI (including customizations) for different workspaces...
Comment 2 Dani Megert CLA 2012-05-09 03:05:29 EDT
(In reply to comment #1)
> While this is an issue it has never been reported as a defect until now. There
> has never been any indication that this will be done and is covered by
> 
> http://www.eclipse.org/eclipse/development/readme_eclipse_4.1.html
> 
> where it's clearly stated:
> 
> "User interface session state may be discarded when a workspace is upgraded."
> 
The 4.2 plan clearly states that workspaces are are portable. See
http://www.eclipse.org/projects/project-plan.php?projectid=eclipse#compatibility


> Dani, how do you migrate this info to new workspaces ?
What info? I don't migrate anything - simply start the 3.8 workspace with 4.2.

I could even mark that bug 'critical' because it is lost data and there is no way I can transfer the 3.8 perspectives to 4.2.
Comment 3 Paul Webster CLA 2012-05-09 07:22:52 EDT
(In reply to comment #2)
> The 4.2 plan clearly states that workspaces are are portable. See
> http://www.eclipse.org/projects/project-plan.php?projectid=eclipse#compatibility
> 

That same section states: "User interface session state may be discarded when a workspace is upgraded."

PW
Comment 4 Paul Webster CLA 2012-05-09 07:22:55 EDT
(In reply to comment #2)
> The 4.2 plan clearly states that workspaces are are portable. See
> http://www.eclipse.org/projects/project-plan.php?projectid=eclipse#compatibility
> 

That same section states: "User interface session state may be discarded when a workspace is upgraded."

PW
Comment 5 Paul Webster CLA 2012-05-09 08:02:27 EDT
Sorry about the doubles, I'm having connection problems here.

Just a note:  Reading the saved perspectives in 3.x starts with org.eclipse.ui.internal.Perspective.loadCustomPersp(PerspectiveDescriptor)

PW
Comment 6 Dani Megert CLA 2012-05-09 08:06:47 EDT
(In reply to comment #5)
> Sorry about the doubles, I'm having connection problems here.
np.


So the question is what "state" means. That I loose all my *saved*
perspectives goes beyond that in my opinion ;-).
Comment 7 Oleg Besedin CLA 2012-05-09 09:38:14 EDT
(In reply to comment #2)
> I could even mark that bug 'critical' because it is lost data and there is no
> way I can transfer the 3.8 perspectives to 4.2.

By the way, 4.0 and 4.1 work the same as 4.2. As far as I know, we keep perspectives / layouts going from 4.1 to 4.2 (and probably 4.0 from 4.2, for basic cases).
Comment 8 Paul Webster CLA 2012-07-25 08:49:52 EDT
*** Bug 385920 has been marked as a duplicate of this bug. ***
Comment 9 Eric Moffatt CLA 2012-07-30 13:16:26 EDT
Dani, if it's OK with you I'll going to re-title this defect and use it to provide the ability to have a separate location to store the UI Model for a workspace. 

There is no hope of cross-translating the 3.x information into 4.x but at least this way you'd only have to change the arrangement once, not for every workspace you have...
Comment 10 Dani Megert CLA 2012-07-31 02:14:09 EDT
(In reply to comment #9)
> Dani, if it's OK with you I'll going to re-title this defect and use it to
> provide the ability to have a separate location to store the UI Model for a
> workspace. 

I'd prefer a summary that describes the bug a users sees. If I understand you correctly, then you want to solve the export/import in 4.x but not support the migration. That's OK, since that train left the station anyway ;-).
Comment 11 Eric Moffatt CLA 2012-07-31 16:06:23 EDT
As per previous comments I'm re-targeting this defect towards providing he ability to have a separate location to store the UI Model instead of under a workspace's .metadata.

Note that the initial implementation will *only* store the UI model since it's far harder to determine which of the rest of the information (i.e. dialog sizes...) is really ui related. This will however contain all the currently (and saved) perspectives so that you won't have to re-do the arrangements for each new WS...
Comment 12 Paul Webster CLA 2012-08-10 14:05:43 EDT
*** Bug 386178 has been marked as a duplicate of this bug. ***
Comment 13 Dani Megert CLA 2012-10-10 06:24:53 EDT
*** Bug 391486 has been marked as a duplicate of this bug. ***
Comment 14 jim taller CLA 2013-01-02 21:22:28 EST
Clearly there is a bug with exporting and importing the perspectives from one version of Eclipse to Eclipse 4.2 and even from project X in Eclipse 4.2 to project Y in Eclipse 4.2.

Here is my workaround in Eclipse 4.2.
1. Set up your desired perspectives in project X.
2. Exit Eclipse.
3. Copy from project X .metadata/.plugin/org.eclipse.e4.workbench/workbench.xmi to project Y the same directory.
4. Start Eclipse and the perspective should be available.
Comment 15 jim taller CLA 2013-01-02 21:25:09 EST
Clearly there is a bug with exporting and importing the perspectives from one version of Eclipse to Eclipse 4.2 and even from project X in Eclipse 4.2 to project Y in Eclipse 4.2.

Here is my workaround in Eclipse 4.2.
1. Set up your desired perspectives in project X.
2. Exit Eclipse.
3. Copy from project X .metadata/.plugin/org.eclipse.e4.workbench/workbench.xmi to project Y the same directory.
4. Start Eclipse and the desired perspective from X should be available in Y.
Comment 16 Geoff Thieme CLA 2013-04-22 14:02:19 EDT
The recommended workbench.xmi work-a-around does not work when sharing general preferences via .epf files. I get conflicts with the keyboard shortcuts (which are stored in both files). This means I don't have any way of sharing perspectives with others in my team.
Comment 17 Eric Moffatt CLA 2013-04-22 15:48:21 EDT
I'll tag this as one of the enhancements we'd *really* like to look at for Luna. 

There are a number of places where information is stored and each would have to be examined to determine whether it should be participating.

Perhaps we're asking the question backwards; should I be able to define a 'stable' location for *all* metadata which in independent of the resource root ?

All we may need is a way in a current workspace's .metadata to specify the 'common' area ? We know that we don't want to lock the user into a single location but it seems clear that a user doing the same type of development on the same machine likely wants to re-use things like preferences, keybindings, dialog sizes as well as the presentation.
Comment 18 Eric Moffatt CLA 2013-11-04 14:33:43 EST
Changing severity to reflect that the defect has been re-targeted.
Comment 19 Kelly McGraw CLA 2014-04-28 14:36:11 EDT
I think this issue is serious enough to warrant a fix in the current release. We have quite a few customers for the Rational set of products with IBM that have custom perspectives and are now moving to our releases based off this version of Eclipse. Can some sort of relief be considered for this version?
Comment 20 Paul Webster CLA 2014-04-28 15:40:55 EDT
No, the enhancement phase is finished for this release of eclipse (Luna).  Are you sure you're not interested in Bug 378644 ?

PW
Comment 21 Kelly McGraw CLA 2014-04-29 09:49:48 EDT
Bug 378644 does not look like the same issue to me.
Comment 22 Paul Webster CLA 2014-04-29 10:34:43 EDT
Saving and importing perspectives is a feature enhancement, and covered by this by this bug.

Bug 378644 is about how you open up an existing 3.x workspace and you're back at the default java perspective (and how to fix that).

PW
Comment 23 Perin Mising name CLA 2014-04-29 12:15:24 EDT
The problem with RDz customers is that the perspective is updated automatically. It has been defined once by an administrator and saved somewhere on the remote system (z/OS). Once a user connects to that remote system, some properties are downloaded and the workspace updated. In particular the perspective, but It could be fonts, colors, and also specific  RDz properties like 'property groups', 'key mapping',.... 
In other word, the solution cannot be 'manual' but automatic in order to keep all the work done before.
Comment 24 Paul Webster CLA 2014-04-29 12:43:10 EDT
(In reply to Perin Mising name from comment #23)
> The problem with RDz customers is that the perspective is updated
> automatically. It has been defined once by an administrator and saved
> somewhere on the remote system (z/OS).

How is this accomplished?

PW
Comment 25 Martin Oberhuber CLA 2014-11-14 07:01:15 EST
Getting the "Save and Restore Perspectives" feature back is really important for provisioning customized Eclipse instances at large adopters. I just talked to a customer and noticed that compared to Eclipse 3, there is a real step back here.

This bug has a "Mars" target milestone, is it going to make Mars ?
Comment 26 Dani Megert CLA 2014-11-14 08:19:52 EST
(In reply to Martin Oberhuber from comment #25)
> Getting the "Save and Restore Perspectives" feature back is really important
> for provisioning customized Eclipse instances at large adopters. I just
> talked to a customer and noticed that compared to Eclipse 3, there is a real
> step back here.
> 
> This bug has a "Mars" target milestone, is it going to make Mars ?

I hope so. It's high on our prio list.
Comment 27 Andrey Loskutov CLA 2015-01-27 14:05:55 EST
(In reply to Martin Oberhuber from comment #25)
> Getting the "Save and Restore Perspectives" feature back is really important
> for provisioning customized Eclipse instances at large adopters. I just
> talked to a customer and noticed that compared to Eclipse 3, there is a real
> step back here.
> 
> This bug has a "Mars" target milestone, is it going to make Mars ?

Martin, can you please check if the "Save and Restore Perspectives" feature you mention covered by the fixes of bug 420956 (included in 4.5 M5). The save/reset perspective works now.

But if you really mean "provisioning customized Eclipse instances", which is about ability to export/import/save some UI Workspace model data (especially targeting to the customized perspective data reuse) - then I guess you have to find someone who must start to work hard on it NOW if you want see it in Mars.
Comment 28 Klaus Klaus CLA 2015-02-12 07:41:34 EST
>> This bug has a "Mars" target milestone, is it going to make Mars ?

>I hope so. It's high on our prio list.

Any hope that it's coming?

It's definitely not working in 4.5M5 ...
Comment 29 Eclipse Genie CLA 2015-03-16 05:55:53 EDT
New Gerrit change created: https://git.eclipse.org/r/43915
Comment 30 Wojciech Sudol CLA 2015-03-16 06:12:02 EDT
(In reply to Eclipse Genie from comment #29)
> New Gerrit change created: https://git.eclipse.org/r/43915

I wrote a simple POC of importing perspectives from epf file exported from Eclipse 3.x (restart is required).
Are there any preferences regarding the format of exporting and importing 4.x perspectives - .epf, separate file, importing directly from Eclipse installation?
Comment 31 Martin Oberhuber CLA 2015-03-16 11:04:22 EDT
(In reply to Wojciech Sudol from comment #30)

The goal would be that I can export my perspective layout in some way that allows having it "imported automatically on startup" for any other people in my team when they launch Eclipse the first time.

plugin_customization.ini would have been one method for doing so in the past; as per Mars, I guess that Eclipse Oomph allows importing any Preference data on startup.

At any rate, having this only supported by explicit UI action would not be sufficient IMO. Some automation must be possible.
Comment 32 Dani Megert CLA 2015-03-17 11:09:08 EDT
(In reply to Martin Oberhuber from comment #31)
> (In reply to Wojciech Sudol from comment #30)
> 
> The goal would be that I can export my perspective layout in some way that
> allows having it "imported automatically on startup" for any other people in
> my team when they launch Eclipse the first time.
> 
> plugin_customization.ini would have been one method for doing so in the
> past; as per Mars, I guess that Eclipse Oomph allows importing any
> Preference data on startup.
> 
> At any rate, having this only supported by explicit UI action would not be
> sufficient IMO. Some automation must be possible.

Let's not extend this bug with new features. The goal is to simply fix/restore the 3.x behavior where one could export and then re-import the preferences. I *think* that approach also allowed to provide the perspectives via plugin_customization.ini.

If you want a new/separate perspective/layout specific import/export, then this needs to be captured in its own feature request.
Comment 33 Lars Vogel CLA 2015-04-08 18:23:13 EDT
(In reply to Dani Megert from comment #32)
> Let's not extend this bug with new features. The goal is to export and then re-import the preferences.

Reading this bug was confusing me, my understanding about this bug is that is is about the ability of exporting and important perspectives via the preference export and import dialog. I adjusted the title accordingly.
Comment 34 Eclipse Genie CLA 2015-04-27 07:16:52 EDT
New Gerrit change created: https://git.eclipse.org/r/46544
Comment 35 Eclipse Genie CLA 2015-04-27 09:31:28 EDT
New Gerrit change created: https://git.eclipse.org/r/46559

WARNING: this patchset contains 1044 new lines of code and may require a Contribution Questionnaire (CQ) if the author is not a committer on the project. Please see:https://wiki.eclipse.org/Project_Management_Infrastructure/Creating_A_Contribution_Questionnaire
Comment 36 Lars Vogel CLA 2015-04-30 08:21:54 EDT
Moving to 4.6, please move back in case you plan to fix that in 4.5
Comment 37 Wojciech Sudol CLA 2015-04-30 10:30:47 EDT
I pushed to gerrit a patch that allows to export and import perspectives (through .epf file) from Eclipse 4.x, and second patch for importing perspectives from Eclipse 3.x. The patches don't import a perspective if in Eclipse a perspective with the same label is open. This is a problem that I will try to fix soon. Anyway, in my opinion the currant patches can be merged to master and the fix for importing open perspective can be added later.
Comment 38 Dani Megert CLA 2015-05-03 11:58:03 EDT
(In reply to Wojciech Sudol from comment #37)
> I pushed to gerrit a patch that allows to export and import perspectives
> (through .epf file) from Eclipse 4.x, and second patch for importing
> perspectives from Eclipse 3.x. The patches don't import a perspective if in
> Eclipse a perspective with the same label is open. This is a problem that I
> will try to fix soon. Anyway, in my opinion the currant patches can be
> merged to master and the fix for importing open perspective can be added
> later.


Thanks Wojciech. I tested it for quite a while and it looks mainly good. The biggest missing piece is with regards to minimized and maximized views:

3x IMPORT
=========
1. start new workspace

2. import perspectives3x.epf
-> as described above, hence expected log message:
!MESSAGE Cannot import perspective "org.eclipse.jdt.ui.JavaPerspective" because a perspective with the same label is open

3. open 'ProjectExplorerAndProblemsView'
-> OK: both views appear as when exported

4. open 'FastAndMinimizedView' perspective
-> bug: minimized view is not minimized
-> bug: minimized view is not minimized

5. open 'MaximizedEditorArea' perspective
-> bug: maximized editor area is not maximized. Probably same error with views


4x IMPORT
=========
1. start new workspace

2. import perspectives4x.epf

3. open 'ProjectExplorerAndProblemsView'
-> OK: both views appear as when exported

4. open 'MinimizedViews' perspective
-> OK: both views are minimized
-> bug: both views are minimized to the left, but on export Problems view was on
        the right

5. open 'MaximizedEditorArea' perspective
-> OK: editor area is maximized and views are minimized
-> bug: all views are minimized to the left
        to see correct state open Debug perspective and maximize editor area
Comment 39 Dani Megert CLA 2015-05-03 11:59:44 EDT
Created attachment 253106 [details]
perspectives3x.epf
Comment 40 Dani Megert CLA 2015-05-03 12:00:10 EDT
Created attachment 253107 [details]
perspectives4x.epf
Comment 41 Dani Megert CLA 2015-05-04 03:00:09 EDT
> -> bug: both views are minimized to the left, but on export Problems view was 
> on the right

The same applies if the view(s) got minimized to the bottom.
Comment 42 Wojciech Sudol CLA 2015-05-11 04:48:30 EDT
I fixed the problem with mimized views in perspective 4x.
Importing perspective that is already open is more problematic. In contrary to Eclipse 3, in Eclipse 4 perspective's ID and label are different (e.g. perspective "Java" has ID "org.eclipse.jdt.ui.JavaPerspective"). At the same time we don't allow to have two perspectives with the same label. A problem occurs when a user creates a custom perspective called e.g. MyPerspective that is based on Java perspective (so its ID is org.eclipse.jdt.ui.JavaPerspective.MyPerspective), opens it and later imports a perspective with the same label, but based on different perspective (e.g. Debug), so its ID is different (in this case org.eclipse.debug.ui.DebugPerspective.MyPerspective).
When a user try to reset it is original MyPerspective, in normal situation the imported perspective should replace the original one. The question is what to do with the perspective ID? There are multiple options:
1. Replace with the imported perspective's ID - may lead to inconsistencies, especially when some plug-ins keeps the perspective ID; moreover it is not possible to change the ID in PerspectiveDescriptor, so it needs to be replaced, causing furrther problems
2. Change the imported perspective ID - less problematic, behaviorally compatible with Eclipse 3, but we lose some information about the perspective, what leads to situation in which we import a perspective and immediatelly after export we get the same perpsective but with different ID. Also the perspective's icon does not update (but this problem already occures in Eclipse 3)
3. Support multiple perspectives with the same label
4. Don't import perspectives with the same label and different ID
5. Modify imported perspective's label

In my opinion only options 2 and 4 make sense. Since option 4 is a regression comparing to Eclipse 3, I opt to choose option 2. Its implementation is already in gerrit. Any comments or other ideas?
Comment 43 Dani Megert CLA 2015-05-26 11:06:37 EDT
(In reply to Wojciech Sudol from comment #42)
> I fixed the problem with mimized views in perspective 4x.

This seems to work now, but 3x IMPORT regarding minimized and maximized stuff is still not working (see comment 38 for the steps).


> In my opinion only options 2 and 4 make sense. Since option 4 is a
> regression comparing to Eclipse 3, I opt to choose option 2. Its
> implementation is already in gerrit. Any comments or other ideas?

Looks fine, i.e. the modified Java perspective works after closing and reopening.
Comment 44 Dani Megert CLA 2015-05-27 05:13:50 EDT
(In reply to Dani Megert from comment #43)
> > In my opinion only options 2 and 4 make sense. Since option 4 is a
> > regression comparing to Eclipse 3, I opt to choose option 2. Its
> > implementation is already in gerrit. Any comments or other ideas?
> 
> Looks fine, i.e. the modified Java perspective works after closing and
> reopening.

Actually using a different ID is not good since that results in loosing all contributions that were made to the perspective, for example the showInPart perspective extensions.

Test Case:
1. start new workspace
2. import perspectives3x.epf
3. close all perspectives
4. open the 'Java' perspective
5. open the Package Explorer
6. context menu > Show In
==> BUG: entries are missing, e.g. Project Explorer
Comment 45 Martin Oberhuber CLA 2015-08-27 10:45:56 EDT
I'm wondering what is the status on this ?

Comment 38 indicates it is working and looking mainly good, except for minimized / maximized views. Target milestone is 4.4.2+ ... is there any chance getting this work finished for 4.5.1 ?
Comment 46 Eclipse Genie CLA 2015-09-22 11:22:59 EDT
New Gerrit change created: https://git.eclipse.org/r/56443
Comment 50 Wojciech Sudol CLA 2015-09-22 12:53:07 EDT
I've rebased and released to master the import/export perspective code, making it disabled by default. This will allow to easily test the feature, without affecting uninterested users (especially in case of a bug).
To enable the feature, Eclipse need to be started with "e4.impExpPerspectiveEnabled=true" system property.
The scenario with perspective label and ID discrepancy is still not supported, i.e. current implementation ignores such perspective.
Comment 51 Patrik Suzzi CLA 2015-09-22 18:44:55 EDT
Created attachment 256773 [details]
Attached image shows the API break on the UI

Seems that one of the commits is breaking the API on org.eclipse.ui.workbench

Below you can see the full text for the four error (in the attached image)

Description	Resource	Path	Location	Type
API analysis aborted for 'org.eclipse.ui.workbench' since its build path is incomplete	org.eclipse.ui.workbench		line 0	Fatal Problem
The project was not built since its build path is incomplete. Cannot find the class file for org.eclipse.emf.ecore.xmi.impl.XMIResourceFactoryImpl. Fix the build path then try building this project	org.eclipse.ui.workbench		Unknown	Java Problem
The type org.eclipse.emf.ecore.xmi.impl.XMIResourceFactoryImpl cannot be resolved. It is indirectly referenced from required .class files	ImportExportPespectiveHandler.java	/org.eclipse.ui.workbench/Eclipse UI/org/eclipse/ui/internal/registry	line 220	Java Problem
Unsatisfied version constraint: 'org.eclipse.emf.ecore.xmi: 2.11.0'	MANIFEST.MF	/org.eclipse.ui.workbench/META-INF	line 110	Plug-in Problem
Comment 52 Wojciech Sudol CLA 2015-09-23 09:48:04 EDT
(In reply to Patrik Suzzi from comment #51)
> Seems that one of the commits is breaking the API on org.eclipse.ui.workbench

I don't see the issue in my environment. As a target platform I use the latest N build which contains org.eclipse.emf.ecore.xmi v2.12, so it should be OK.
Comment 53 Andrey Loskutov CLA 2015-09-23 14:25:36 EDT
(In reply to Wojciech Sudol from comment #52)
> (In reply to Patrik Suzzi from comment #51)
> > Seems that one of the commits is breaking the API on org.eclipse.ui.workbench
> 
> I don't see the issue in my environment. As a target platform I use the
> latest N build which contains org.eclipse.emf.ecore.xmi v2.12, so it should
> be OK.

This is really unfortunate decision. I'm currently also trying to setup my workspace but I have no idea where the EMF nightly builds are supposed to be. 
EMF http://www.eclipse.org/modeling/emf/updates/ page doesn't contain anything useful pointing in this direction and 
/org.eclipse.ui.releng/platformUiTools.p2f is not of help either.

Could we revert this manifest change or at least fix platformUiTools.p2f to point to the right emf update site?
Comment 54 Paul Webster CLA 2015-09-23 15:58:49 EDT
(In reply to Andrey Loskutov from comment #53)
> 
> Could we revert this manifest change or at least fix platformUiTools.p2f to
> point to the right emf update site?

If we don't have a .target file for Platform UI then platformUiTools.p2f should be updated so it is relevant.

PW
Comment 55 Eclipse Genie CLA 2015-09-24 02:32:20 EDT
New Gerrit change created: https://git.eclipse.org/r/56586
Comment 56 Wojciech Sudol CLA 2015-09-24 11:21:18 EDT
By mentioning N-build, I only wanted to emphasize that I tried to reproduce the issue with the latest available build. I didn't notice the issue with older I-builds and 4.5 builds too.
Eventually I reproduced the issue and I updated the platformUiTools.p2f file with commit
http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=18411e5a73284b99c062f6f9e2696f89ae538917 what solved the problem in my environment.
Patrik, Andrey, could you verify if the patch works for you?
Comment 57 Patrik Suzzi CLA 2015-09-24 14:42:14 EDT
(In reply to Wojciech Sudol from comment #56)

> Patrik, Andrey, could you verify if the patch works for you?

This is almost working, one last issue in downgrading version, at 
BindingService.java line 292: 
Type mismatch: cannot convert from HashSet<Object> to HashSet<Binding>	

tested with Build I20150922-0800
Comment 58 Lars Vogel CLA 2015-09-24 14:56:28 EDT
(In reply to Patrik Suzzi from comment #57)
> This is almost working, one last issue in downgrading version, at 
> BindingService.java line 292: 
> Type mismatch: cannot convert from HashSet<Object> to HashSet<Binding>	
> 
> tested with Build I20150922-0800

I had this two (cause by me via Bug 472654) but after Project -> Clean, this error was gone for me. Can you try that?
Comment 59 Markus Keller CLA 2015-09-24 15:37:11 EDT
The spurious compile error in BindingService.java is tracked in bug 478346. It was introduced in I20150922-0800 and is most likely a compiler bug.
https://git.eclipse.org/r/#/c/56660/ is a good workaround for now.
Comment 60 Patrik Suzzi CLA 2015-09-24 15:41:09 EDT
Created attachment 256829 [details]
It seems the problem it's the same

(In reply to Lars Vogel from comment #58)
> I had this two (cause by me via Bug 472654) but after Project -> Clean, this
> error was gone for me. Can you try that?

In my case it is still not ok. 

tested with: 
- Eclipse Build I20150922-0800
- Last commit on my Git tree : 6d5812a7b94e2f428a6039b5f973583177da75d3 (A.Blewitt, 4 hrs ago)
- Eclipse SDK Installation Details > EMF version 2.11.0.v20150601-0402
Comment 61 Patrik Suzzi CLA 2015-09-24 15:49:15 EDT
(In reply to Markus Keller from comment #59)
> The spurious compile error in BindingService.java is tracked in bug 478346.
> It was introduced in I20150922-0800 and is most likely a compiler bug.
> https://git.eclipse.org/r/#/c/56660/ is a good workaround for now.

Markus, I'm totally Ok with you.
Comment 62 Eclipse Genie CLA 2015-10-08 03:14:11 EDT
New Gerrit change created: https://git.eclipse.org/r/57689
Comment 63 Kalyan Prasad Tatavarthi CLA 2015-10-08 03:16:09 EDT
Added Gerrit Change so as to fix the issue reported in comment #44.
for 3.x perspective import
Comment 65 Eclipse Genie CLA 2015-10-12 04:55:56 EDT
New Gerrit change created: https://git.eclipse.org/r/57966
Comment 67 Dani Megert CLA 2015-10-12 06:17:49 EDT
(In reply to Kalyan Prasad Tatavarthi from comment #63)
> Added Gerrit Change so as to fix the issue reported in comment #44.
> for 3.x perspective import

I verified that both scenarios now work (but one has to export the 4.x cases to perspectives4x.epf first).

Also, the Java perspective is imported and works.
Comment 68 Eclipse Genie CLA 2015-10-13 02:43:05 EDT
New Gerrit change created: https://git.eclipse.org/r/58044
Comment 69 Kalyan Prasad Tatavarthi CLA 2015-10-13 02:46:10 EDT
Made changes so that the import of 4.x perspectives also read the ShowIn tag information from registry as it is being done in the case of 3.x perspective import so as to not lose any ShowIn tag information.
Comment 71 Eclipse Genie CLA 2015-10-15 08:34:28 EDT
New Gerrit change created: https://git.eclipse.org/r/58236
Comment 72 Kalyan Prasad Tatavarthi CLA 2015-10-15 08:40:57 EDT
Added a new cumulative patch with all changes for backporting this fix to Eclipse 4.4.2
Comment 73 Dani Megert CLA 2015-10-16 05:36:16 EDT
(In reply to Kalyan Prasad Tatavarthi from comment #72)
> Added a new cumulative patch with all changes for backporting this fix to
> Eclipse 4.4.2

While testing that patch I noticed two things that are not working yet (also with the code in master):

Import 'perspectives3x.epf
- Fast view from 3.x is not minimized in 'FastAndMinimizedView' perspective
- In the 'MaximizedEditorArea' perspective the minimized views at the bottom should be on the right and not on the left (minor issue).
Comment 74 Kalyan Prasad Tatavarthi CLA 2015-10-20 05:23:02 EDT
I have ammended the patch provided on 4.4.2 to fix the Fast Views related issue that Dani has reported
Comment 75 Dani Megert CLA 2015-10-20 13:24:28 EDT
(In reply to Kalyan Prasad Tatavarthi from comment #74)
> I have ammended the patch provided on 4.4.2 to fix the Fast Views related
> issue that Dani has reported

I don't see a new version.
Comment 76 Eclipse Genie CLA 2015-10-20 13:57:27 EDT
WARNING: this patchset contains 1809 new lines of code and requires a Contribution Questionnaire (CQ), as author kalyan_prasad@in.ibm.com is not a committer on platform/eclipse.platform.ui. Please see:https://wiki.eclipse.org/Project_Management_Infrastructure/Creating_A_Contribution_Questionnaire
Comment 77 Eclipse Genie CLA 2015-10-21 06:03:12 EDT
New Gerrit change created: https://git.eclipse.org/r/58592
Comment 78 Kalyan Prasad Tatavarthi CLA 2015-10-21 06:04:51 EDT
Added a new patch set for handling FastViews in perspectives during migration from 3.x to 4.x
Comment 79 Wojciech Sudol CLA 2015-10-22 11:10:35 EDT
(In reply to Eclipse Genie from comment #77)
> New Gerrit change created: https://git.eclipse.org/r/58592

I get unexpected result with the following scenario:
1. Run Eclipse 3.8.2 with a fresh workspace
2. Open Java perspective, right click on Problems view's tab and choose "Fast View" - it should be minimized to bottom left corner of the window
3. Save this perspective as MyPerspective
4. Export preferences to a file
5. Run Eclipse 4.6 with the patch
6. Import the preferences file and open the MyPerspective

Result:
In the imported perspective, the Problems view is minimized but located at the top of left trim.
Comment 80 Wojciech Sudol CLA 2015-10-27 10:52:34 EDT
(In reply to Wojciech Sudol from comment #79)
> Result:
> In the imported perspective, the Problems view is minimized but located at
> the top of left trim.

Kalyan, can you reproduce this issue?
Comment 81 Kalyan Prasad Tatavarthi CLA 2015-11-03 04:14:19 EST
I have been able to reproduce the issue and have update the patch to fix this issue. Wojciech has found another more serious issue during the import of 3.x perspectives when the view is not available in the current Eclipse environment. I have also found a similar issue during 4.x perspective import. This scenario is resulting in multiple NullPointerExceptions. I am currently looking into fixing this issue.
Comment 82 Kalyan Prasad Tatavarthi CLA 2015-11-03 04:15:41 EST
Created attachment 257694 [details]
testcase for 3x perspective changes with missing views
Comment 83 Kalyan Prasad Tatavarthi CLA 2015-11-03 04:16:48 EST
Created attachment 257695 [details]
testcase for 4.x perspective changes with missing views
Comment 84 Kalyan Prasad Tatavarthi CLA 2015-11-04 00:59:08 EST
I have appended the current patch to include fix for issue of import of 3.x and 4.x perspectives when the view is not available in the current Eclipse environment.
Comment 87 Kalyan Prasad Tatavarthi CLA 2015-12-08 01:32:43 EST
Verified in the Eclipse integration build I20151207-2000
Comment 88 Eclipse Genie CLA 2015-12-22 03:38:32 EST
New Gerrit change created: https://git.eclipse.org/r/63125
Comment 89 Kalyan Prasad Tatavarthi CLA 2015-12-22 03:39:33 EST
Created a new gerrit patch to backport these changes to 4.5 maintenance branch
Comment 91 Beirti O 'Nunain CLA 2016-01-12 10:13:29 EST
Any ETA on a patch for this? I miss being able to share perspectives between workspaces
Comment 92 Dani Megert CLA 2016-01-12 10:20:54 EST
(In reply to Beirti O 'Nunain from comment #91)
> Any ETA on a patch for this? I miss being able to share perspectives between
> workspaces

This is fixed in master, e.g.
http://download.eclipse.org/eclipse/downloads/drops4/I20160105-1000/
and will be part of Mars.2 (4.5.2).
Comment 93 Dani Megert CLA 2016-01-26 09:26:26 EST
(In reply to Eclipse Genie from comment #86)
> Gerrit change https://git.eclipse.org/r/58236 was merged to
> [R4_4_maintenance].
> Commit:
> http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=807e99692a618dde238605b07c75084a29137d60
> 

==> Marking as FIXED.
Comment 94 Thomas Schindl CLA 2016-02-29 18:53:17 EST
Arghhhhhh - this breaks the widget independency of the e4 - you are adding JFace/SWT to the central component of e4 and hence you break e(fx)clipse runtime layer completely in a 4.5.x release!

http://git.eclipse.org/c/platform/eclipse.platform.ui.git/diff/bundles/org.eclipse.e4.ui.workbench/META-INF/MANIFEST.MF?id=807e99692a618dde238605b07c75084a29137d60

I'm speechless! if you are interested what this means for down stream you can follow https://bugs.eclipse.org/bugs/show_bug.cgi?id=488730 but in boils down to us not being able to adopt Mars.2 - This patch needs to be rolled back please!
Comment 95 Thomas Schindl CLA 2016-02-29 21:30:43 EST
First people are already hitting the bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=488725
Comment 96 Kalyan Prasad Tatavarthi CLA 2016-02-29 23:34:46 EST
Reopening the bug to fix the issue of removing the addition of swt dependency to e4
Comment 97 Martin Oberhuber CLA 2016-03-01 01:24:27 EST
Hmm, while I agree that the dependency is problematic ... the offending commit was on 19-Nov-2015, so I'm surprised why this is discovered only now ?

http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=807e99692a618dde238605b07c75084a29137d60

I'm not trying to imply that e(fx)clipse downstream did anything wrong here, I'm just wondering from a Platform PMC / Eclipse AC point of view what could be improved here to promote early testing...
Comment 98 Dani Megert CLA 2016-03-01 02:28:27 EST
(In reply to Martin Oberhuber from comment #97)
> Hmm, while I agree that the dependency is problematic ... the offending
> commit was on 19-Nov-2015, so I'm surprised why this is discovered only now ?
> 
> http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=807e99692a618dde238605b07c75084a29137d60
> 
> 
> I'm not trying to imply that e(fx)clipse downstream did anything wrong here,
> I'm just wondering from a Platform PMC / Eclipse AC point of view what could
> be improved here to promote early testing...

And it is also in Neon M4 and M5.

Kalyan is working on a fix. Would it help to provide a modified org.eclipse.e4.ui.workbench for Mars.2 which contains the fix? I'm not in favor of respinning the whole release train.
Comment 99 Lars Vogel CLA 2016-03-01 02:34:07 EST
(In reply to Martin Oberhuber from comment #97)
> Hmm, while I agree that the dependency is problematic ... the offending
> commit was on 19-Nov-2015, so I'm surprised why this is discovered only now ?
> 
> http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/
> ?id=807e99692a618dde238605b07c75084a29137d60
> 
> I'm not trying to imply that e(fx)clipse downstream did anything wrong here,
> I'm just wondering from a Platform PMC / Eclipse AC point of view what could
> be improved here to promote early testing...

We definitely need to add tests to avoid such a thing in the future. Opened Bug 488738 for that.
Comment 100 Thomas Schindl CLA 2016-03-01 02:52:53 EST
(In reply to Dani Megert from comment #98)
> (In reply to Martin Oberhuber from comment #97)
> > Hmm, while I agree that the dependency is problematic ... the offending
> > commit was on 19-Nov-2015, so I'm surprised why this is discovered only now ?
> > 
> > http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=807e99692a618dde238605b07c75084a29137d60
> > 
> > 
> > I'm not trying to imply that e(fx)clipse downstream did anything wrong here,
> > I'm just wondering from a Platform PMC / Eclipse AC point of view what could
> > be improved here to promote early testing...
> 
> And it is also in Neon M4 and M5.

As e(fx)clipse is releasing every 6-8 weeks can't switch our nightly builds to the platform nigthlies (Neon nor maint) as then then I'd ship different versions of the upstream code than then one I'd publish at the end of the cycle.

So the first time I could have noticed the problem was when 4.5.2 was released and David pushed its content to http://download.eclipse.org/eclipse/updates/4.5. Not sure about the date but I guess it was the 26th of Feb?

> 
> Kalyan is working on a fix. Would it help to provide a modified
> org.eclipse.e4.ui.workbench for Mars.2 which contains the fix? I'm not in
> favor of respinning the whole release train.

Great. Yes I'm fine with having a "org.eclipse.e4.ui.workbench" I can consume somewhere from who does not have a org.eclipse.jface, no need to respin the complete release train.
Comment 101 Eclipse Genie CLA 2016-03-01 03:32:23 EST
New Gerrit change created: https://git.eclipse.org/r/67585
Comment 102 Martin Oberhuber CLA 2016-03-01 03:46:38 EST
(In reply to Thomas Schindl from comment #100)
> As e(fx)clipse is releasing every 6-8 weeks can't switch our nightly builds
> to the platform nigthlies (Neon nor maint)

I understand this argument regarding the build, but what about a separate Hudson Job which would test with a different Platform base ?

In the TCF Project, our master build is (still) against eclipse-3.8.2 but we also build against 4.3, 4.4, 4.5, 4.6 and we also test the master bits against 4.6 ... and that has actually saved our neck by exposing an API change in the Neon CDT that we had to adapt to ... not claiming that our build pipeline is perfect but just showing the idea :)
Comment 103 David Williams CLA 2016-03-01 15:00:42 EST
(In reply to Martin Oberhuber from comment #102)
> (In reply to Thomas Schindl from comment #100)
> > As e(fx)clipse is releasing every 6-8 weeks can't switch our nightly builds
> > to the platform nigthlies (Neon nor maint)
> 
= = = = = = Off topic = = = = =
I will add my surprise that this wasn't caught early. e(fx)clipse is part of the Simultaneous Release, right? Seems that sort of obligates you to build against the to-be-released code before it is released. I see you are also not following my advice (that I give to everyone) that you should not build against the "SimRel" repository, but against the original repositories of the projects you depend on. Plus, I always advise people to build against simple repositories, not composites. For many reasons, but reproducibility being one of the most important. I'll also comment  in bug 488725. 

= = = = = =

Back on topic, how should we, the Eclipse Platform deliver this fix? I have opened bug 488787 to discuss what is needed and track the mechanics of it, instead using *this* bug for everything. :) 

Thanks,
Comment 104 Eclipse Genie CLA 2016-03-07 14:06:49 EST
New Gerrit change created: https://git.eclipse.org/r/67913
Comment 105 Eclipse Genie CLA 2016-03-07 14:11:39 EST
New Gerrit change created: https://git.eclipse.org/r/67914
Comment 106 Eric Moffatt CLA 2016-03-08 09:55:41 EST
I'm in the process of reviewing the latest patch but I'm unsure of how to go about testing the effects of the patch.

I can't switch workspaces while running a debug session (similar to Bug 222107, a regression perhaps?)

I tried to import the two supplied pref files but they don't seem to cause any changes in the UI (I looked for new perspectives...), what should I be doing ?
Comment 107 Eric Moffatt CLA 2016-03-08 09:57:47 EST
BTW, the two new patches above are for the maintenance streams...
Comment 108 Kalyan Prasad Tatavarthi CLA 2016-03-08 10:13:46 EST
Comment 38 explains the way to test this bug fix
Comment 109 Kalyan Prasad Tatavarthi CLA 2016-03-08 10:21:54 EST
Comment 38 and comment 73 describe the expected behavior testing with the attached perspective3x.epf and perspective4x.epf

The latest patch is related to the issue reported in the comment 81
the two attached epf files  "testcase for 3x perspective changes with missing views" and  "testcase for 4x perspective changes with missing views" are used to test this scenario.
Comment 111 Eclipse Genie CLA 2016-03-08 11:26:30 EST
New Gerrit change created: https://git.eclipse.org/r/67976
Comment 112 Kalyan Prasad Tatavarthi CLA 2016-03-08 11:27:22 EST
The new change set fixes the issue of reset  perspective failing if imported perspective has missing views
Comment 113 Kalyan Prasad Tatavarthi CLA 2016-03-08 11:34:18 EST
Modified the patches for the maintenance streams 

https://git.eclipse.org/r/67913
and
https://git.eclipse.org/r/67914

to containe the reset perspective fix
Comment 117 Markus Keller CLA 2016-03-08 14:53:12 EST
(In reply to Kalyan Prasad Tatavarthi from comment #113)
Pushed to 4.4.2+ and 4.5.2+.

In R4_4_maintenance, no bundle version changes were necessary, since both bundles already got touched after R4_4_2.

In R4_5_maintenance, increased the bundles versions.
Comment 118 Kalyan Prasad Tatavarthi CLA 2016-03-16 03:14:51 EDT
Verified in Eclipse Integration Build I20160315-2000
Comment 119 David Williams CLA 2016-05-01 13:50:22 EDT
As I started to look at bug 488787, I looked here as the "fix needed" and noticed the target. I changed the target to 4.5.2+. Let me know if I have misunderstood, or gotten the wrong bug!
Comment 120 David Williams CLA 2016-05-01 13:53:13 EDT
(In reply to David Williams from comment #119)
> As I started to look at bug 488787, I looked here as the "fix needed" and
> noticed the target. I changed the target to 4.5.2+. Let me know if I have
> misunderstood, or gotten the wrong bug!

Nevermind. Discovered by own misunderstanding by reading the previous comments. This was/is intended for 4.4.2+ as well.