It's all about the answers!

Ask a question

How to get unresolved changes of a repository workspace using java API

Karthick Ravichandran (111) | asked Oct 12 '18, 8:10 a.m.
edited Oct 12 '18, 12:37 p.m. by David Lafreniere (4.7k7)
We are able to get the OutgoingChangeSets using the below code. But is there a way to find the unresolved changes of the workspace?

      IChangeHistorySyncReport changeHistorySyncReport =
              WorkspaceComparisonFlags.CHANGE_SET_COMPARISON_ONLY, Collections.EMPTY_LIST, monitor);

      List<IChangeSetHandle> outgoingChangeSets = changeHistorySyncReport.outgoingChangeSets();


One answer

permanent link
David Lafreniere (4.7k7) | answered Oct 12 '18, 11:26 a.m.
None of the Filesystem client layer is official API.
You can use it, but per non-API, it is subject to change at any time.

For example, here is a snippet of code that might help.

    protected boolean hasUncheckedInChangesInWorkspace(IProgressMonitor monitor) {
        boolean uncheckedInChangesExist = false;
        IWorkspace workspace = getWorkspace();
        if (workspace != null) {
            ILocalChangeManager lcm = FileSystemCore.getSharingManager().getLocalChangeManager();
            ISharingManager sm = FileSystemCore.getSharingManager();
            Collection<ISandbox> sandboxes = sm.getRegisteredSandboxes();
            SubMonitor subMonitor = SubMonitor.convert(monitor, sandboxes.size());
            outter: for (ISandbox sandbox : sandboxes) {
                Collection<? extends IConfigurationDescriptor> loadedComponents = null;
                try {
                    loadedComponents = sandbox.allLoadedConfigurations(subMonitor.newChild(1));
                } catch (FileSystemException exception) {
                    // TODO log exception
                for (IConfigurationDescriptor loaded : loadedComponents) {
                    if (loaded.getConnectionHandle() instanceof IWorkspaceHandle) {
                        IComponentHandle component = loaded.getComponentHandle();
                        ILocalChange[] localChanges = lcm.getPendingChanges(workspace, component, sandbox);
                        if (localChanges.length > 0) {
                            uncheckedInChangesExist = true;
                            break outter;
        return uncheckedInChangesExist;

Karthick Ravichandran commented Oct 17 '18, 7:39 a.m. | edited Oct 17 '18, 7:46 a.m.
 Many Thanks for your reply!
Since our code is running with the help of plain java server API’s  and not the eclipse plugin setup, the pending changes are not been retrieved and it always end with the error message: “org.eclipse.debug.core.DebugException: com.sun.jdi.ClassNotLoadedException: Type has not been loaded occurred while retrieving component type of array”

Also, we have figured out that the error message is coming from :
   public ILocalChange[] getPendingChanges(IContextHandle connection,IComponentHandle component, ISandbox sandbox) {
  LocalChangeTracker tracker = findTracker(connection, component, sandbox.getRoot());
if (tracker == null)
return NO_CHANGES;  // control returns from here.
return tracker.getPendingChanges();

Let us know if we are missing anything here. Thanks.

David Lafreniere commented Oct 17 '18, 9:25 a.m.

Nope, you're not missing anything. Take a look at the Java package that ILocalChangeManager is in, which is: "". I.e. all this code is client-side code. The server does not know about these 'unresolved' changes (which is a client-side concept).

Karthick Ravichandran commented Oct 23 '18, 5:46 a.m.

I would like to put my question in other way. Do we have any API which gives us the files which are modified and are not yet checked-in.

David Lafreniere commented Oct 23 '18, 9:53 a.m.

"Pending local changes" or "Unresolved changes" or "files which are modified and are not yet check-in" are all the same thing. There is the API I mentioned above, but this API is client-side API. The server has no concept of this and thus there is no API on the server.

Your answer

Register or to post your answer.