Summary: | core resources API dependency on core.runtime.compatibility | ||
---|---|---|---|
Product: | [Eclipse Project] Platform | Reporter: | Jim des Rivieres <jeem> |
Component: | Resources | Assignee: | DJ Houghton <dj.houghton> |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | normal | ||
Priority: | P1 | CC: | jeffmcaffer |
Version: | 3.0 | ||
Target Milestone: | 3.0 M9 | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: |
Description
Jim des Rivieres
2004-04-20 17:45:56 EDT
Is this something that we should be targeting for 3.0? Yes. This requires an API change. I've upped it to P1. Can it be addressed for the Tuesday April 27 I-build? I've deprecated it and replaced it with the following. Does that sound ok? The comment is essentially the same as the deprecated method. Let me know and I will release to HEAD. /** * Returns the location in the local file system of the project-specific * working data area for use by the given bundle or <code>null</code> * if the project does not exist. * <p> * The content, structure, and management of this area is * the responsibility of the plug-in. This area is deleted when the * project is deleted. * </p><p> * This project needs to exist but does not need to be open. * </p> * @param bundle the bundle * @return a local file system path * @since 3.0 */ public IPath getWorkingLocation(Bundle bundle); The replacement method should take a String plug-in id, rather than a Bundle. This has the advantage of allowing the working area to be computed without forcing the client to look up the bundle. Agreed. Released to HEAD. |