Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[wtp-pmc] Requesting respin of WTP 3.2.3 for bugs 336881, 333901, and 334921

As you may have noticed, the priority for the subject bugs has been elevated to P1.  These three have been found during testing of our SR2 deliverable using WTP alone, and I'd like to ask we respin to fix them.  The first is a performance and functional regression, the second corrupts project metadata, and the third is a usability problem in a very mainline scenario.  Although I'm intent on Source Editing and JSDT producing 3.2.4 releases, I'd rather avoid putting out a bad release at all than patch it in our update site or wait until that release to fix them.  If these remain in our SR2 deliverable, fixes would not appear in a simultaneous Release build until Indigo.

All 3 are up for PMC review and require +4 for their inclusion.  The questionnaires are filled out in the respective bugs, but I'm appending summaries here as well.  While no other components should be affected by these changes, given how late I'm proposing them, I want to make sure everyone is aware of them.

Bug 336881
This problem has been reported to us by a customer of an adopter product and is a regression from the WTP 3.2.2 Release and reproducible in WTP itself.

What breaks:
Valid JSP comments causes numerous problems.  Comments containing text resembling a tag results in extra text regions being stored in our model, at a rate of one region per character.  If the comment contains a tag embedded within another tag, it results in the parser not properly closing the comment in our structured document.--all text in the document after the comment is still considered part of the comment, even though the comment is correctly closed as written.  This degrades editing performance, produces an incorrect DOM model, causes incorrect syntax coloring, and generates a very long, and false, Error marker/annotation about the comment not being closed.  There is no way for the user to get around this issue.

What we'd like to change:
We want to roll back a series of changes around the handling of comments in JSP files, properly fixing the original problem (bug 326193) that led us down the this path, and adding new unit tests to ensure we keep handling comments correctly in the future.  It's not a perfect rollback because we're keeping a change that removed the unnecessary tracking of line numbers in our tokenizer (which also caused compiler messages about never reading the value).  Attachment 188961 shows the extra in-memory objects that are created and  attachment 188962 shows the case where a comment consumes the remainder of the file's text.

Sample content to illustrate the problems:
<!-- if (a<b) -->

<!--<link HREF=''localhost/file.css'/>'>-->

this text will be considered part of the comment
<as will="this"/>

Bug 33901
This revisits the topic of properly setting the initial source folder of a _javascript_ project, specifically when it's a web project.  Depending on when the _javascript_ Facet/Nature is installed, the default source folder(s) may or may not include the folders that will be deployed into the web application.  A previous attempted to make things so that regardless of the order in which the _javascript_ and Module Core natures were installed, the correct default paths would be set.

What breaks:
Entries other than the default source folders were supposed to be copied while updating the Include Path, but as the original testing was done with additional Include Path Entries that had attributes on them, we didn't catch the faulty logic whereby entries without attributes were simply dropped.  This means that any facet that adds a library or container to the _javascript_ Include Path before the Module Core nature is installed (and our resource change listener reacts to its installation) will be removed unless it specifies attributes on its Include Path Entry.  Even if all existing entries made it through properly, the output location (left over from JDT) was set to an incorrect value, and the ordering of the Include Path Entries was not preserved.

What we'd like to change:
It's a larger fix that originally intended, but the looping algorithm is corrected by the patch so that all entries are retained while preserving the original ordering of those entries in the Include Path.

Bug 334921
Creating a static web project results in it not appearing in the Project Explorer.  Actually, creating any _javascript_ capable project wouldn't appear in the Project Explorer.

What's broken:
Leftover functionality in JSDT's common navigator contributions removes the IProject from the viewer and attempts to add the IJavaScriptProject as a child of the _javascript_Model.  As the model is not in the viewer, it does not reappear.  JDT handles this by converting resources back and forth between the JDT versions and the plain IResources, and doing the same worked in our Script Explorer.  It does not work that simply in the Project Explorer.

What we'd like to change:
Avoid both the removal and addition of the project from the Project Explorer, instead refreshing the IProject object in the viewer to make sure the decorators take effect.  Also, adjust what's being refreshed in the Script Explorer to keep it working.

Thank you,
Nitin Dahyabhai
Eclipse WTP Source Editing and JSDT
IBM Rational

Back to the top