#310 VSS java.lang.IllegalArgumentException when moving a file

v1.0 (example)
Steve M.

I am coming across a java.lang.IllegalArgumentException when trying to move a file. To reproduce:

1- Create a Java project
2- Add a Java class to your project
3- Add the project to VSS using the VSS plugin
4- Commit changes to the Java class unto VSS (if not already done)
5- Create a new package to your project (without "VSS" it)
6- Move the Java class to the newly created package
7- IllegalArgumentException:

java.lang.IllegalArgumentException: Attempted to beginRule: R/, does not match outer scope rule: L/SomeJavaProject/src/SomeClass.java
at org.eclipse.core.runtime.Assert.isLegal(Assert.java:62)
at org.eclipse.core.internal.jobs.ThreadJob.illegalPush(ThreadJob.java:122)
at org.eclipse.core.internal.jobs.ThreadJob.push(ThreadJob.java:232)
at org.eclipse.core.internal.jobs.ImplicitJobs.begin(ImplicitJobs.java:80)
at org.eclipse.core.internal.jobs.JobManager.beginRule(JobManager.java:225)
at org.eclipse.core.internal.resources.WorkManager.checkIn(WorkManager.java:117)
at org.eclipse.core.internal.resources.Workspace.prepareOperation(Workspace.java:1744)
at org.eclipse.core.internal.resources.Resource.refreshLocal(Resource.java:1416)
at org.eclipse.core.internal.resources.File.refreshLocal(File.java:331)
at org.vssplugin.ui.EditorUtils$4.runInWorkspace(EditorUtils.java:278)
at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:38)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)

(I have recorded an .AVI if interested in viewing the exact sequence)

Some analysis:
The plugin has a dedicated org.eclipse.team.core.RepositoryProvider subclass named VSSPluginProvider which is used when a given project is registered unto VSS.

Among other things a RepositoryProvider will set the resources rule factory used to determine the scheduling rules that are to be obtained when performing various resource operations (e.g. move, copy, delete, etc.) on the resources in the project the provider is mapped to. This will happens when associating a project to a given RepositoryProvider instance - see RepositoryProvider.map().

However, by default the resource rule factory will be PessimisticResourceRuleFactory factory which above will always return the workspace root for all rules.

As the VSSPluginProvider class from VSS plugin doesn't override RepositoryProvider.getRuleFactory() method, we can be sure that the resource rule factory used by this VSS plugin will always be a PessimisticResourceRuleFactory factory.

This means that for all rule creation - file resource - we will always get as the associated scheduling resource:


While the outer scope of the rule creation defined previously for the WorkspaceModifyOperation will be:


Hence, the exception is caused because the scheduling rules don't have the same scope.

* RepositoryProvider javadoc:
* PessimisticResourceRuleFactory javadoc :

Reading in more detail the javadoc for RepositoryProvider.getRuleFactory(), it is advice to "override this method and provide a subclass of ResourceRuleFactory that provides rules of a more optimistic granularity (e.g. project or lower)".

This sentence makes all this sense in the current case here as the VSS plugin doesn’t follow this advice.

Even more, looking at the Eclipse bugs base for "beginRule IllegalArgumentException", you can found some entries which are quite similar (and sometimes the same) as the problem faced. For example:

Job Rule error when generating entities in a team-shared project

JobManager.beginRule() should allow addition of non-contained rules

With all that, I would rather tend to believe that the issue is a mix between Eclipse bug(s) and a "loose" implementation of the RepositoryProvider subclass used in the VSS plugin.

Remark about scheduling rule:
"L" stands for file
"R" stands for Root
"P" stands for Project
"F" stands for Folder


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks