Community
Participate
Working Groups
See bug 124662 comment 18, this bug is the first part of bug 124662 implementation which has been split due to the fact that it was too risky at this late stage of 3.3 development. As ICompilationUnit#becomeWorkingCopy(IProblemRequestor, IProgressMonitor) can be called several times, it's definitely not clear what happens when different requestors are provided. The main problem is: which requestors will be really notified of the problems?! To make it this API clearer and easier to use by client, we'll make WorkingCopyOwner having a problem requestor and use this requestor by default while perform becomeWorkingCopy operation on an ICompilationUnit. Then problems will be reported only to this unique problem requestor. Note taht if client continues to specify their own problem requestor and use existing becomeWorkingCopy API, problems will be reported on the specified requestor *and* also on the working copy owner one... Here APIs we'll add to address this requirement: org.eclipse.jdt.core.WorkingCopyOwner: /** * Returns the problem requestor used while reconciling a working copy of this * working copy owner (see {@link ICompilationUnit#reconcile(boolean, * WorkingCopyOwner, IProgressMonitor)}. * <p> * By default, no problem requestor is configured. Clients can override this * method to provide a requestor. * </p> * * @param workingCopy The problem requestor used for the given working copy. * If <code>null</code>, then return the problem requestor used for all working * copies of the working copy owner. * @return the problem requestor to be used by working copies of this working * copy owner or <code>null</code> * if no problem requestor is configured. * * @since 3.3 */ public IProblemRequestor getProblemRequestor(ICompilationUnit workingCopy) org.eclipse.jdt.core.ICompilationUnit: /** * Changes this compilation unit handle into a working copy. * A new {@link IBuffer} is created using this compilation unit handle's owner. * Uses the primary owner is none was specified when this compilation unit * handle was created. * <p> * When switching to working copy mode, problems are reported to the * {@link IProblemRequestor problem requestor} of the {@link WorkingCopyOwner * working copy owner}. * </p> * <p> * Once in working copy mode, changes to this compilation unit or its children * are done in memory. * Only the new buffer is affected. Using {@link #commitWorkingCopy(boolean, * IProgressMonitor)} will bring the underlying resource in sync with this * compilation unit. * </p> * <p> * If this compilation unit was already in working copy mode, an internal * counter is incremented and no other action is taken on this compilation unit. * To bring this compilation unit back into the original mode (where it reflects * the underlying resource), {@link #discardWorkingCopy} must be call as many * times as {@link #becomeWorkingCopy(IProblemRequestor, IProgressMonitor)}. * </p> * * @param monitor a progress monitor used to report progress while opening this * compilation unit or <code>null</code> if no progress should be reported * @throws JavaModelException if this compilation unit could not become a * working copy. * @see #discardWorkingCopy() * @since 3.3 */ void becomeWorkingCopy(IProgressMonitor monitor) throws JavaModelException;
I would like to see the patch, assuming the old method would get deprecated.
+1 for the API
Created attachment 59793 [details] Proposed patch
Comment on attachment 59793 [details] Proposed patch Obsolete because I forgot to deprecate becomeWorkingCopy(IProblemRequestor, IProgressMonitor) method.
While adding the deprecation on becomeWorkingCopy(IProblemRequestor, IProgressMonitor) makes me feel that ICompilationUnit.getWorkingCopy(WorkingCopyOwner, IProblemRequestor, IProgressMonitor) should also be deprecated... Jerome, Martin, what's your mind about this?
I agree. There's also a 3rd case in IClassFile.
Agree to deprecate ICompilationUnit.getWorkingCopy(WorkingCopyOwner, IProblemRequestor, IProgressMonitor). For the third case on IClassFile, I guess Martin meant IClassFile.becomeWorkingCopy(IProblemRequestor, WorkingCopyOwner, IProgressMonitor). If we deprecate this one, then we must add becomeWorkingCopy(WorkingCopyOwner, IProgressMonitor), otherwise it won't be possible for a class file to become a working copy (even if I think this functionality is not used right now).
Can a class file really 'become' a working copy? Or is 'getWorkingCopy(WorkingCopyOwner...)' what is does?
(In reply to comment #8) > Can a class file really 'become' a working copy? Or is > 'getWorkingCopy(WorkingCopyOwner...)' what is does? > You are right. I had forgotten that IClassFile#becomeWorkingCopy(...) returns a ICompilationUnit handle and should really be called getWorkingCopy(...). So if we deprecate IClassFile#becomeWorkingCopy(...), we should just put a reference to ITypeRoot#getWorkingCopy(WorkingCopyOwner, IProgressMonitor).
Created attachment 60492 [details] Complete proposed patch This patch deprecates following methods: - ICompilationUnit #becomeWorkingCopy(IProblemRequestor, IProgressMonitor #getWorkingCopy(WorkingCopyOwner, IProblemRequestor, IProgressMonitor) - IClassFile #becomeWorkingCopy(IProblemRequestor, WorkingCopyOwner, IProgressMonitor) - WorkingCopyOwner #newWorkingCopy(String,IClasspathEntry[],IProblemRequestor,IProgressMonitor)
Note that migration from deprecated methods to new API ones (ie. without problem requestor as parameter) was not really trivial and can represent a big amount of work for existing clients. I'll complete this patch by one or several FAQ in JDT porting guide of org.eclise.jdt.doc.isv to give some advice on how to use the new API methods without changing the behavior of the existing code...
Created attachment 60544 [details] Proposed FAQ entry in porting guide documentation
'null' is spec'ed as a valid argument to WorkingCopyOwner.getProblemRequestor. Is that necessary? From the usages it seems that this doesn't happen. Other than that: The API looks good. In the spec I wouldn't write 'is reported twice' but rather 'is reported on the passed problem requester as well as on the problem requestor returned by the working copy owner (if not null)'
Agree that it looks good and agree with comment #13. Otherwise minor issues: - typo in ICompilationUnit#becomeWorkingCopy(IProgressMonitor): "Uses the primary owner *is* none" - changes to IJavaElementDelta's Javadoc are not part of the solving of this issue - why is the phrasing changed in WorkingCopyOwner#newWorkingCopy(String, IClasspathEntry[], IProblemRequestor, IProgressMonitor) ? It feels like a change in behavior
Created attachment 60688 [details] New proposed patch based on v_741 (In reply to comment #13) > 'null' is spec'ed as a valid argument to WorkingCopyOwner.getProblemRequestor. > Is that necessary? From the usages it seems that this doesn't happen. > Removed in this new patch > Other than that: The API looks good. In the spec I wouldn't write 'is reported > twice' but rather > 'is reported on the passed problem requester as well as on the problem > requestor returned by the working copy owner (if not null)' > Fixed in this new patch (In reply to comment #14) > Agree that it looks good and agree with comment #13. > Otherwise minor issues: > - typo in ICompilationUnit#becomeWorkingCopy(IProgressMonitor): "Uses the > primary owner *is* none" > Fixed in this new patch > - changes to IJavaElementDelta's Javadoc are not part of the solving of this > issue > I've released this change independently => no longer in new patch > - why is the phrasing changed in WorkingCopyOwner#newWorkingCopy(String, > IClasspathEntry[], IProblemRequestor, IProgressMonitor) ? It feels like a > change in behavior > Put back old phrasing in this new patch
Patches (code and doc) released for 3.3 M6 in HEAD stream.
Verified for 3.3 M6 using build I20070320-0010
