I'm glad your team found and could fix
these serious issues before our SR2 deadline ... but, that deadline is
today! I'd have to re-read them to see if they are valid "exceptions"
to take to Planning Council after today (they might be, I'm just saying
I'd have to re-read them, and better if we did not have to). Even if we
have to put on update site, instead of in the release itself, we will at
least have time to do that before 25th.
So, I suggest while waiting for complete
review/approval, you go ahead and release these three fixes in maintenance
branch. If there's any issues/problems, we can at least drop back to what
we already have ... but, if you are still awake (or, get up early) starting
a build as soon as possible maximizes the chances of getting a build done
in time ... confirming the fixes, etc. Be sure to check manifest versions
(if need to be incremented) and I'd suggest to go ahead and re-tag all
containing features, to make sure we do not run into the auto-suffix limitations.
Longer term, I'd like to hear your thoughts
on how these types of regressions sneak into our code, and why it takes
so long to find them. I doubt there's any specific, easy, obvious solution
... but ... seems worth discussing. Maybe a few minutes at Thursday's status
Thanks again for finding/fixing these
02/15/2011 06:58 PM
respin of WTP 3.2.3 for bugs 336881, 333901, and
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.
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
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
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) -->
this text will be considered part of the comment
This revisits the topic of properly setting the initial source folder of
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
default paths would be set.
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
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.
Creating a static web project results in it not appearing in the Project
appear in the Project Explorer.
Leftover functionality in JSDT's common navigator contributions removes
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.