Bug 332486 - [api] Add API to get non-primary working copy from IStorageEditorInput
Summary: [api] Add API to get non-primary working copy from IStorageEditorInput
Status: CLOSED WONTFIX
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Text (show other bugs)
Version: 3.7   Edit
Hardware: All All
: P5 enhancement (vote)
Target Milestone: ---   Edit
Assignee: JDT-Text-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords: api
Depends on:
Blocks:
 
Reported: 2010-12-13 19:17 EST by Jeff Johnston CLA
Modified: 2019-11-14 17:39 EST (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jeff Johnston CLA 2010-12-13 19:17:09 EST
The Linux Tools ChangeLog plugin automatically prepares ChangeLog entries for changes made to a project that has been imported from a Team repository (e.g. CVS, SVN).

For Java files, one of the things it attempts to do is to automatically report the Java method where a change has occurred. Sometimes a change will occur whereby an entire method is removed and so it does not exist in the local copy. A diff can be found from the Team plugins for such a change which documents the line numbers in the old file where one can find the old method name.

The plugin via the Team classes can access the archived repository contents and create a StorageEditorInput. It then attempts to get an ICompilationUnit from which it can call getJavaElement() for the range of changes in the repository file.

To get this compilation unit, it cannot call getWorkingCopy() from the working copy manager. For example,

		// Get the working copy and connect to input.
		IWorkingCopyManager manager = JavaUI.getWorkingCopyManager();
		manager.connect(input);

		ICompilationUnit workingCopy = manager.getWorkingCopy(input);
		
		if (workingCopy == null)
			return "";
		
		IJavaElement method = workingCopy.getElementAt(offset);
		
		manager.disconnect(input);



This fails and after doing some debugging, it is only because the getWorkingCopy() call restricts its results to primaryOnly and so returns null.

The code can be made to work by knowing that the JavaUI.getDocumentProvider() is returning an ICompilationUnitDocumentProvider and thus we can call its getWorkingCopy() method directly as is done in the WorkingCopyManager class, only we don't restrict the results. Changing the getWorkingCopy call above to be:

		ICompilationUnitDocumentProvider x = (ICompilationUnitDocumentProvider)JavaUI.getDocumentProvider();
		// Retrieve the Java Element in question.
		ICompilationUnit workingCopy = x.getWorkingCopy(input);



works. This successfully figures out the method of an offset within the repository source..

Of course, this is frowned upon because ICompilationUnitDocumentProvider is declared internal.

So, the information is out there, but there is no clean way to do this.

I had posted this on the Eclipse forum and received no answers so I am requesting the functionality formally so that I may make my plug-in API clean.
Comment 1 Dani Megert CLA 2010-12-14 03:44:48 EST
Note that there is already enough API to achieve this (though a bit more code would be needed, see org.eclipse.jdt.core.WorkingCopyOwner.newWorkingCopy(String, IClasspathEntry[], IProgressMonitor).
Comment 2 Jeff Johnston CLA 2010-12-14 13:05:12 EST
(In reply to comment #1)
> Note that there is already enough API to achieve this (though a bit more code
> would be needed, see
> org.eclipse.jdt.core.WorkingCopyOwner.newWorkingCopy(String, IClasspathEntry[],
> IProgressMonitor).

So to use this I would have to first create a temporary file using the storage contents or did you have something else in mind?
Comment 3 Dani Megert CLA 2010-12-15 05:10:05 EST
Take a look at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitDocumentProvider.createFakeCompiltationUnit(IStorageEditorInput, boolean).
Comment 4 Jeff Johnston CLA 2019-11-14 17:39:25 EST
Closing this off the books.