Community
Participate
Working Groups
Created attachment 150655 [details] Extensions tab I was editing a new plugin in the Extensions tab and saving it as I go. I ended up in the state where it had created an invalid plugin.xml PW
Created attachment 150656 [details] plugin.xml tab
Build: I20091027-0100 The PDE editor is munging quite a bit of the plugin.xml. I added a separator and then dragged it to be between my third and fourth child at that level. It inserted the <separator id="what" visible="false"></separator> in the middle of the attributes of the 3rd and 4th children, rendering the XML invalid. PW
Needs investigation
This also effects the DS editor: org.eclipse.pde.ds.ui.editor It inserted a property in the middle of a closing tag. PW
The PDE Editor has been corrupting the XML for an entire milestone now, this urgently needs to get fixed. PW
I hit this last Friday and am hearing reports on IRC.
Created attachment 153946 [details] Errors from the PDE Editor I got these errors from the PDE editor while trying to reproduce the problem. PW
OK, I'm working on org.eclipse.ui.tests/plugin.xml (from HEAD/platform-ui-tests) Add org.eclipse.ui.menus EP at the end of the file, add a menuContribution, to that add a couple of commands and a menu in the middle, to the menu add a couple of commands and a menu in the middle. save Switch to plugin.xml and delete the innermost <menu>...</menu> block and save. Switch back to Extensions and that block is still displayed. If you update parts of the extension after that block (and sometimes before) it will potentially slice out parts of your XML or corrupt it. I got: <command commandId="org.e<command commandId="org.eclipse.ui.tests.command42" id="Y" label="Y" mnemonic="Y" style="push"> </command> PW
This time the error was accompanied by some sysout: Error: Could not parse XML contribution for "org.eclipse.ui.tests//home/users/pwebster/down/tmp_360/org.eclipse.ui.tests/plugin.xml". Any contributed extensions and extension points will be ignored. PW
if I'm not mistaken PDE XML editors are using string concatination to create the XML. Anybody know when this started happening, we might be able to track it back to a particular code change.
Happens on Windows too.
(In reply to comment #10) > if I'm not mistaken PDE XML editors are using string concatination to create > the XML. Anybody know when this started happening, we might be able to track it > back to a particular code change. It looks like the PDE projects are now mirrored as Git repositories (see http://dev.eclipse.org/git/) - I can recommend using "git bisect" for finding the offending commit. Use a Mac or a Linux box for this to make it easy to install the git command line client. For a success story with "git bisect", see http://jbowes.wordpress.com/2007/02/18/git-bisect-a-practical-example-with-yum/
Moving to M5. We have not been able to reproduce and haven't found any possible causes yet.
Created attachment 154363 [details] Exceptions before saving changed extensions I just got the attached AssertionFailedException and MalformedTreeException in M4 before saving changed extension elements. These look a bit like they could be responsible for corrupting a document.
*** Bug 298802 has been marked as a duplicate of this bug. ***
One of the ways i was able to reproduce this was by positining the cursor in the plugin.xml tab with in some XML text, then going to the Extension point tab, and adding some extensions. When I went back to the plugin.xml tab, it had inserted the extension point code where the cursor was, not where the extension point updates were to occur.
To reproduce try the following: Create new plugin project "de.vogella.pdebug". Add dependency to "org.eclipse.core.runtime". Using the "Extensions" tab add extension "org.eclipse.core.runtime.products" with application="org.eclipse.e4.ui.workbench.swt.E4Application" name="My App". Add property "appName" with any value. Stop and check the plugin.xml -> You have several times "org.eclipse.core.runtime.products" included. ------------ Works everytime for me (in the sense that plugin.xml is corrupted).
Tried Lars steps and also tried Dave's suggestion of moving the cursor around. Couldn't reproduce in I20091217-0819 or in a workbench running on PDE Head. I wasn't seeing any collapsing in the tree either (the two problems feel related). What VMs are people using?
This is one of the two famous "ghost in the machine" bugs in PDE. The editor code hasn't changed much for awhile. I have trouble reproducing this bug also. I know it exists though :)
I'm using java version "1.6.0_17". Shall I do a screencast to demonstrate how I do it?
(In reply to comment #18) > Tried Lars steps and also tried Dave's suggestion of moving the cursor around. > Couldn't reproduce in I20091217-0819 or in a workbench running on PDE Head. I > wasn't seeing any collapsing in the tree either (the two problems feel > related). > > What VMs are people using? I'm running on Ubuntu Linux Karmic Koola, with Sun Java 6 jvm. I've given up trying to use the UI and just using the painful plugin.xml editor directly (really wish this leverage wtp's xml editor). Only if I start using the UI does the XML get messed up.
(In reply to comment #18) > Tried Lars steps and also tried Dave's suggestion of moving the cursor around. > Couldn't reproduce in I20091217-0819 or in a workbench running on PDE Head. I > wasn't seeing any collapsing in the tree either (the two problems feel > related). > > What VMs are people using? I'm on linux (FC10 at home and RHEL5.3 at work) and I'm using the IBM JDK 1.5 when I see it. PW
I uploaded a screencast which shows the problem to my server. This can be found here: http://www.vogella.de/temp/pdebug.avi
In addition I can offer a remote (debugging) session to demonstrate this bug; I can easily reproduce it.
I also have the same problem which give me much trouble, I am using: Eclipse: 3.6 M1 -> M4, JDK: 1.6.0_18 Platform: Windows XP I tried the latest 3.5.2RC1, the Plug-in Manifest Editor just works fine, This problem is only on Eclipse 3.6, and remains unfixed through M1 to M4.
This bug is biting us big time. I hope there is a solution soon.
This feature is radio-active and fails with minimal interaction. Please fix it soon since the work-around is tedious and time consuming. Many thanks in advance.
Moving to major. Paul hasn't seen the problem recently and the PDE team has not been able to reproduce it. Paul will attempt to reproduce next week, and if possible, we'll remotely debug the problem.
Let me know if you need help; until now I can easily reproduce this.
Created attachment 162109 [details] one part fix I managed to reproduce this consistently. I found that in the the case of an attribute replace the length of the text being replace was always set to be the length of the new (replacement) string. This works fine, except when the new attribute is shorter than the original, then you get messed up attribute strings. Steps (that worked for me): 1. add an adapter factory extension 2. change it a few times saving between the changes 3. press undo more than once (without saving inbetween) 4. save. Expected: all is well. Happens: XML is hosed, there may not be an error, depending on what you changed, but if you changed attributes At this point switching to the XML text section and pressing undo (until the XML looks sane) would fix the problem for me.
(In reply to comment #30) > I managed to reproduce this consistently. looks like we need to do a pass through the code and find all usage of ReplaceEdit and make sure the offset / lengths are correct.
PDE is using ReplaceEdit incorrectly in a number of classes, passing the length of the new text rather than the length of the text to replace. I will look at a broader fix. However, the PDE code has been like this for some time (years), so I don't know why this is being seen more now.
Created attachment 162184 [details] Updated fix I went through all the places that PDE uses ReplaceEdit. At first glance they appeared to be incorrect, but in several cases the node has the correct old length stored. Calling ReplaceEdit(node.getOffset, node.getLength, node.write) is valid because getLength returns a stored int, not the length of the node.write string. XMLInputContext was the only place that I debugged through where the lengths are incorrect.
I have committed the fix to HEAD. There were two places I wasn't able to debug to where there could still be a problem. In XMLInputContext#addElementContentOperation (I don't know of anywhere in the PDE editors that we add text content to an element). The other is XMLTextChangeListener, which is used in the tests and a utility class, but I wasn't able to hit the specific code path using ReplaceEdit. After debugging the other cases, I feel reasonably confident that the length is being used correctly in those cases.
@Curtis: Thanks. Do you know if this will be picked up by the next e4 milestone build? If yes, I can test this fix easily.
(In reply to comment #35) > @Curtis: Thanks. Do you know if this will be picked up by the next e4 milestone > build? If yes, I can test this fix easily. It'll show up next Wed or Thurs (in the middle of eclipsecon :-) PW
