RE: [wtp-dev] Platform just made a huge improvement to theIWorkspace.validateEdit facility in the M6 code stream...
Thanks! Do you think we need one bug for all of WTP, one
bug for each component, or should we test and open bugs for specific problem
areas that we find?
Konstantin, As soon as the platform declares an I build with this
fix, I will update our dependency and spin a build. Do you want to open a WTP level bug to cover the porting
effort to the new API in WTP? Or is there one already?
Thanks, John Lanuti
IBM Web Tools Platform Technical Lead, IBM
IBM Software Lab - Research Triangle Park,
... we should plan on picking up their next i-build as soon as possible
because we will need time to go through our code and tweak all the places that
we call validateEdit to take advantage of this. Here is a link to the platform
bug that has just been resolved for those interested in the discussion and a
quick summary of the problem. https://bugs.eclipse.org/bugs/show_bug.cgi?id=160905
provides an IWorkspace.validateEdit() method that should be called prior to
modifying files in order to make sure that the team provider has a chance to
take steps to make the file writable (contacting the source-control server,
etc.). The validateEdit method takes a "context" parameter which is of type
Object. The expectation up until now was that you either pass in an instance of
the Shell or null depending on whether user prompting was acceptable. This works
reasonably well for editors, but when file i/o is buried underneath layers of
api, there is no way to get your hands on a Shell object. A lot of team
providers are written to fail the validateEdit call when the Shell is not
provided because they want to interract with the user. One team provider that
behaves this way is the "default team provider" that takes care of making
read-only files writable when no team provider has been configured for the
project. It will fail with "file is read-only" excepion if the Shell is not
provided. Not only is this a bad user experience (user expects to be prompted to
make the file writable), but a lot of the calling code is not written to
gracefully recover from such a failure. In any case, what the platform team has
done to fix this issue is add a special flag that can be passed into the
validateEdit method instead of a Shell object. Passing in this flag will cause
platform internals to locate an appropriate Shell to give to the team provider.
The new flag is IWorkspace.VALIDATE_PROMPT. Ideally all the component teams
should commit to find places in the WTP codebase that need to be modified to use
the new prompt flag for 2.0. This can be done by either scanning the code
(looking for calls to validateEdit as well as IFile.setContents) or by testing
to see what areas need attention. An easy way to test for these problems is to
create a project with some content and then make the entire project directory
read-only (including all the . files and the contents of the .settings
directory). The next step is to try manipulating the project. Everything that's
accessible via project properties is suspect as file io in these contexts is
definitely burried beneath api layers.
We (BEA's WTP team) will be doing our part (testing,
opening bugs, and fixing issues) and we hope that other teams will step forward
and help cover areas that we cannot cover.
03/01/2007 03:51 PM
"General discussion of project-wide or architectural issues."
|"General discussion of project-wide
or architectural issues." <wtp-dev@xxxxxxxxxxx>
|[wtp-dev] Platform just made a huge
improvement to the
IWorkspace.validateEdit facility in the M6 code
This email message, together with any attachments, may
information of BEA Systems, Inc., its
subsidiaries and affiliated
entities, that may be
confidential, proprietary, copyrighted and/or
privileged, and is intended solely for the use of the individual
named in this message. If you are not the intended recipient,
received this message in error, please immediately return this
by email and
then delete it.