Community
Participate
Working Groups
I know it can not be guaranteed that once a workspace is opened ("migrated") to a new IDE version, that it would remain compatible with older IDE versions, but a) seems we'd want to warn people, if we knew of cases, and b) prevent obvious incompatibilities, if possible. There's a lot of unknowns in this case, but thought I'd report what I know, since could effect "M5". First unknown, in my case, is that so far, I'm using a cobbled together near M5 version of WTP, based on Eclipse SDK I20120120-2200. One of the first "near M5" WTP built: http://build.eclipse.org/webtools/committers/wtp4x-R3.4.0-I/20120124034642/I-3.4.0-20120124034642/ I opened my (large) "wtp head" workspace, was playing around with things (noticing lots of odd "compile errors") and thought I'd go back to check things with my M3 based IDE (which was based on Eclipse-SDK-4.2M3). I was quite surprised that even though the workbench would open, no "projects" appeared in Project Explorer (nor Resource View) and there were lots of "ArrayIndexOutOfBoundsException" exceptions in log, which I'll attach. But, seems related to changes related to "platform:/" URL handling? !MESSAGE Exception occurred while rendering: org.eclipse.e4.ui.model.application.ui.basic.impl.PartImpl@4c154c15 (elementId: org .eclipse.jdt.ui.PackageExplorer, tags: [categoryTag:Java, View], contributorURI: null) (widget: ContributedPartRenderer$2 {}, re nderer: org.eclipse.e4.ui.workbench.renderers.swt.ContributedPartRenderer@7ee87ee8, toBeRendered: true, onTop: false, visible: t rue, containerData: null, accessibilityPhrase: null) (contributionURI: bundleclass://org.eclipse.ui.workbench/org.eclipse.ui.int ernal.e4.compatibility.CompatibilityView, object: null, context: PartImpl (org.eclipse.jdt.ui.PackageExplorer) Context, variable s: [], label: Package Explorer, iconURI: platform:/plugin/org.eclipse.jdt.ui//icons/full/eview16/package.gif, tooltip: Working S ets, dirty: false, closeable: true, description: null) I'll see if I can come up with a simpler case. Again, may be unavoidable "backwards migration" problems ... but, thought I'd report in case it helps know about the issue ahead of time.
Created attachment 210028 [details] log full of array index out of boundes exceptions
I tried some cleaner, simpler cases with good news and bad. First, trying to simmulate "a real user" started with plan 3.7.1 SDK, impored a few porjects (I picked all 'jdt' and 'ant' ones in from running platform target (with source). Cleaned, rebuilt. shutdown. Then with my freshly installed 4.2 near M5 SDK only (not WTP) I could open the 37.1 SDK fine. cleaned, brebuilt. shutdown. Then could go back and open same workspace with 3.7.1 sdk. That's the good news. Tried the same thing, but starting off with 4.2 M3, imported some, etc, as before. Then opened that workspace with 4.2 (near) M5 ... all fine, but then when back and tried to open that workspace with 4.2 M3 again and same problem with showing no resources, many ArrayIndexOutOfBoundsExceptions. So ... still don't know if it is an "4.2 M3 problem" only ... or, if it is a 4.x (such as 4.1!) general migration problem ... and ... I need to get some sleep. :/ Can try more test permutations tomorrow, if nothing obvious comes to mind, for others
(In reply to comment #2) > So ... still don't know if it is an "4.2 M3 problem" only ... or, if it is a > 4.x (such as 4.1!) general migration problem ... and ... I need to get some > sleep. :/ > > Can try more test permutations tomorrow, if nothing obvious comes to mind, for > others You can go from M3 to M5, but you can't go back to M3 as we'll have re-written all of the platform:/plugin/id/FQCN to bundleclass:/id/FQCN in the deltas.xml. If that's the only problem, in theory deleting the deltas.xml will fix it before re-opening with 4.2M3. Dean, does that sound right? PW
Yes that is true. When M5 starts the reconciler will re-write the contribution uris to the new format. Whether we can start up a workspace ok without the delta file ... that I don't know. If someone where really stuck I guess some searching and replacing in the delta file would fix the problem too (yuck).
(In reply to comment #4) > Whether we can start up a workspace ok without the delta file ... that I don't > know. > Yes, that's OK, you just go back to the default perspective. It's our last-gasp recovery mechanism for model changes that aren't quite correct. PW
I have confirmed that removing (renaming) the file .metadata/.plugins/org.eclipse.e4.workbench/deltas.xml allowed my old IDE to once again "come up" on the workspace. I've also confirmed the problem happens if I start with the released 4.1.1 (and try to go back to that, after using 4.2 near-M5). So, this is a 4.x issue only ... not the "more mainstream", historically, 3.x IDEs (so that's good). While workspace migration compatibility is never guaranteed, I suppose in a perfect world there might be a couple of ways to improve the situation, but not sure -- in the big picture of things -- if it is worth too much effort: A. the contribution URIs would just be added to (not re-write) so that either version would still "open". (I've no idea what the file is for, sorry to confess, so not sure if this makes sense). B. perhaps better, in 4.1.2 (it would be required soon, since we are nearing RC2) some fall back logic could be added so it'd know to at least not blindly throw the exceptions and instead restore the contribution URI's it needed (in effect, ignore/delete the file itself and "restore" it as it needed) ... it is always good to have a fall back when dealing with workspace (or project) metadata ... 4.2 should have one too, in case 4.3 makes some other "breaking" change :)
After some IM chats today (with Remy and Dani) the "consensus" was it was not worth fixing workspace backwards compatibility issues. If anyone _really_ needed to keep both 4.1 and 4.2 working on same projects, they can import/export/link projects and ... there is even a work around for this specific case, to delete the 'deltas.xml' file if anyone needs a one-time "go backwards" case. So, closing as 'won't fix'. Please say if there's some special way to warning of this specific case, (e.g. in readme) though there is already a general statement that in general workspaces are not "backwards" compatible. I've changed title to make this bug easier to find, in future (hopefully). [Others comments still welcome. Don't mean to close off conversation about it ... just stating current "plan". ]
