Community
Participate
Working Groups
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.
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...
(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.
(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
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
(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 ;-).
(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).
*** Bug 385920 has been marked as a duplicate of this bug. ***
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...
(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 ;-).
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...
*** Bug 386178 has been marked as a duplicate of this bug. ***
*** Bug 391486 has been marked as a duplicate of this bug. ***
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.
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.
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.
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.
Changing severity to reflect that the defect has been re-targeted.
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?
No, the enhancement phase is finished for this release of eclipse (Luna). Are you sure you're not interested in Bug 378644 ? PW
Bug 378644 does not look like the same issue to me.
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
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.
(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
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 ?
(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.
(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.
>> 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 ...
New Gerrit change created: https://git.eclipse.org/r/43915
(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?
(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.
(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.
(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.
New Gerrit change created: https://git.eclipse.org/r/46544
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
Moving to 4.6, please move back in case you plan to fix that in 4.5
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.
(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
Created attachment 253106 [details] perspectives3x.epf
Created attachment 253107 [details] perspectives4x.epf
> -> 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.
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?
(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.
(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
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 ?
New Gerrit change created: https://git.eclipse.org/r/56443
Gerrit change https://git.eclipse.org/r/46544 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=44602e8cad4720515c7e309b45d93a3b69dbc43b
Gerrit change https://git.eclipse.org/r/46559 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=7f4149fcdecd8c30a2a816f8d7e1091759deccdf
Gerrit change https://git.eclipse.org/r/56443 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=950553e8b2a8df725b465dbd5b67a869d50265d9
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.
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
(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.
(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?
(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
New Gerrit change created: https://git.eclipse.org/r/56586
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?
(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
(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?
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.
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
(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.
New Gerrit change created: https://git.eclipse.org/r/57689
Added Gerrit Change so as to fix the issue reported in comment #44. for 3.x perspective import
Gerrit change https://git.eclipse.org/r/57689 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=c02821d659cd502143d153a61712e3b206d57c03
New Gerrit change created: https://git.eclipse.org/r/57966
Gerrit change https://git.eclipse.org/r/57966 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=2cc655dd67c0b6f6f71ca715327872c6d86250af
(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.
New Gerrit change created: https://git.eclipse.org/r/58044
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.
Gerrit change https://git.eclipse.org/r/58044 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=1363d5137680624ebed721e0a9b0d982dc0719c8
New Gerrit change created: https://git.eclipse.org/r/58236
Added a new cumulative patch with all changes for backporting this fix to Eclipse 4.4.2
(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).
I have ammended the patch provided on 4.4.2 to fix the Fast Views related issue that Dani has reported
(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.
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
New Gerrit change created: https://git.eclipse.org/r/58592
Added a new patch set for handling FastViews in perspectives during migration from 3.x to 4.x
(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.
(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?
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.
Created attachment 257694 [details] testcase for 3x perspective changes with missing views
Created attachment 257695 [details] testcase for 4.x perspective changes with missing views
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.
Gerrit change https://git.eclipse.org/r/58592 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=80dedaf70ed93211e0c689b8d814ba2326b25f9c
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
Verified in the Eclipse integration build I20151207-2000
New Gerrit change created: https://git.eclipse.org/r/63125
Created a new gerrit patch to backport these changes to 4.5 maintenance branch
Gerrit change https://git.eclipse.org/r/63125 was merged to [R4_5_maintenance]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=4b17577b9a1a592c1f71a6a1756bb8d3c29b2cb1
Any ETA on a patch for this? I miss being able to share perspectives between workspaces
(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).
(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.
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!
First people are already hitting the bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=488725
Reopening the bug to fix the issue of removing the addition of swt dependency to e4
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...
(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.
(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.
(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.
New Gerrit change created: https://git.eclipse.org/r/67585
(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 :)
(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,
New Gerrit change created: https://git.eclipse.org/r/67913
New Gerrit change created: https://git.eclipse.org/r/67914
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 ?
BTW, the two new patches above are for the maintenance streams...
Comment 38 explains the way to test this bug fix
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.
Gerrit change https://git.eclipse.org/r/67585 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=3224b0b65f03b5460ae0a5702550b618f3ee5033
New Gerrit change created: https://git.eclipse.org/r/67976
The new change set fixes the issue of reset perspective failing if imported perspective has missing views
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
Gerrit change https://git.eclipse.org/r/67976 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=2cc70c445f09c7a7eb8c2412ffc642b5a9804311
Gerrit change https://git.eclipse.org/r/67913 was merged to [R4_5_maintenance]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=57f6271ce3634984e4ffb42c30c3a42c88ccef22
Gerrit change https://git.eclipse.org/r/67914 was merged to [R4_4_maintenance]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=deab545128aedfaa9e711b3502617b8826ccb290
(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.
Verified in Eclipse Integration Build I20160315-2000
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!
(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.