Community
Participate
Working Groups
There are still two unsolved glitches: - "doubling" of newly created class in a new package. Just start creating Java classes a.A, b.B, c.C and so on and soon or late after 4 to 10 iteration you will the glitch. - the sort order of the packages under the src tree gets confused. Example: you have "a" and "b" packages created and sorted well. When you create a Java class in "c" package it might appear between "a" and "b".
It seems that the sorter causes the doubling of the packages. While debugging I stopped the sorter before sort is applied and the package I have created was on top, after the sort the package was doubled.
Created attachment 72571 [details] proposed patch Hi, There is a problem in Project Explorer with doubling and incorrect sorting in, which cause is I think in Eclipse navigator ui. Steps to reproduce using latest Eclipse 3.3 + WTP RC4: 1. Open project explorer. 2. Create java project 3. Create package named “a” 4. Create package named “b” Result b is before a 5. Create package named “c” Result c is doubled on first and last place. The problem is that the added nodes are not registered soon enough in NavigatorContentService (rememberContribution) this causes the CommonViewerSorter.compare method to get null as a result for contentService.getSourceOfContribution. From this on it tries to find the first suitable source of contribution using possible children. Usually it discovers extension in org.eclipse.jst.servlet.ui, if I remove this extension it discovers Working sets source contribution in both ways sorting fails and doubling occurs in the tree. Here is a patch, which solves this, however I haven’t got sufficient knowledge about navigator.ui and I am not sure if the patch is ok. The patch executes rememberContribution on pipelineAdd if the extension is not overridden.
Can you take a look at the suggested patch? The issue is important for an adopter (SAP) of the Europa release and he wants to know if the patch is valid. It is late for any changes in Europa, but there is still possibility for the adopter to apply the fix in his own code base. Is it possible to have the solution as an official patch? Like the once defined by the WTP project: http://wiki.eclipse.org/WTP_Release_1.5_Patches
(In reply to comment #3) > Is it possible to have the solution as an official patch? We haven't done anything like this in the past. I would suggest that you apply this patch in your codebase until it becomes available in a release (3.3.1 or 3.4). Just to understand the severity of this better - does this bug lead to potential data loss, or a memory leak? ("critical" is defined as: crashes, loss of data, severe memory leak) As for the patch itself, it would be best to wait for Michael's assessment.
Hi Boris, The Severity classification does not cover usability. For us, this is quite significant usability regression that was introduced in the early Release Candidate phase (see bug 186627). The problem was introduced because of a cross project (JDT and WTP) change and among all other things, we believe, it uncovered some old bug in the Platform UI. During the RC phase we correct the bigger part of the problem. Maybe this patch is all that is left and we want to be sure that it will not introduce some other problem. Our product, that is based on Europa, goes in validation in a few days and we have not much time to apply the patch in our code base. This is the reason for my request for quicker review. If you do not agree with the Severity, please correct it.
I just wanted to understand how important this fix is. Your original description does not say whether this is happening all the time, or just in rare cases. However, I could already tell from the e-mail to the dev mailing list that it is urgent. :-)
It is always reproducible. However, the effect is not always achieved on creating the 2nd class. Sometimes it happens on 3rd, 4th or even 5th. But at the end it always happens.
The patch is okay, but a more robust solution is provided. It follows the same basic idea, but just ensures that the registered source is: (i) the highest priority extension which (ii) contributes to the overridden parent and (iii) could potentially provide the given child.
Lowering severity to major to reflect technical severity. Raising priority to P1 to reflect business severity.
Created attachment 72971 [details] A patch which registers the added elements to their best match element
A supplemental patch will be needed as the JST Java provider doesn't properly register its ICompressedNode parents. See bug 195293.
Kaloyan and Dimitar -- would you review the attached patch? I have released the CNF portion to HEAD. If you're okay with it, I'll go ahead and close this bug as FIXED. I would propose this for 3.3.1 as well.
Thank you for the help and the new patch. We will validate the patch in our product and will give feedback.
We have tested the patches in series of automated and non automated tests and we did not spot any problems. The patches solved both doubling and sorting. We did not noticed any degradation in the rest of the tests.
The patch was tested together with the one provided in bug 195293.
Hi Michael, Does the patch included in the 3.3.1 stream as well? I have tried the M20070718-0800 3.3.1 build and patch is not applied there, while it seem to appear in the I20070724-0800 3.4 build. Greetings, Kaloyan
The patch has been released for 3.3.1.
The fix for this bug caused regression bug 201784. For more information, please see bug 201784 which I just routed over to Platform UI.
Verified with WTP 2.0.1 RC1 - includes eclipse-SDK-M20070905-1045 build.
