... 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 Basically, platform 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. <http://www.eclipsecon.org/2007/> Konstantin Komissarchik Staff Software Engineer Phone: 206.296.2962 IM: kosta0120 on Yahoo [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> BEA Systems, Inc. 999 North Northlake Way Seattle, WA 98103 www.bea.com <http://www.bea.com/> Barring that natural expression of villainy which we all have, the man looked honest enough. Mark Twain
_______________________________________________________________________ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
spacer.gif
Description: spacer.gif
image130x101.gif
Description: image130x101.gif
bealogo_sig_tl_r.gif
Description: bealogo_sig_tl_r.gif
_______________________________________________ wtp-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/wtp-dev
