[wtp-pmc] Requesting respin of WTP 3.2.3 for bugs 336881, 333901, and 33

[Nitin Dahyabhai <nitind@xxxxxxxxxx>]

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