Community
Participate
Working Groups
Subclipse users that have upgraded to 3.2M5 are reporting that they cannot checkout projects using Subclipse. The following exception occurs: java.lang.IllegalArgumentException: Attempted to beginRule: R/, does not match outer scope rule: P/SimpleJava at org.eclipse.core.runtime.Assert.isLegal(Assert.java:58) at org.eclipse.core.internal.jobs.ThreadJob.illegalPush(ThreadJob.java:116) at org.eclipse.core.internal.jobs.ThreadJob.push(ThreadJob.java:225) at org.eclipse.core.internal.jobs.ImplicitJobs.begin(ImplicitJobs.java:58) at org.eclipse.core.internal.jobs.JobManager.beginRule(JobManager.java:218) at org.eclipse.core.internal.resources.WorkManager.checkIn(WorkManager.java:96) at org.eclipse.core.internal.resources.Workspace.prepareOperation(Workspace.java:1681) at org.eclipse.core.internal.resources.Project.open(Project.java:832) at org.eclipse.core.internal.resources.Project.open(Project.java:890) at org.tigris.subversion.subclipse.core.commands.CheckoutCommand.basicRun(CheckoutCommand.java:116) at org.tigris.subversion.subclipse.core.commands.CheckoutCommand$1.run(CheckoutCommand.java:210) We are running project.open(null) in our code that triggers this. The problem seems to be due to a change in this function: public ISchedulingRule modifyRule(IResource resource) { //modifying the project description requires the root if (resource.getType() == IResource.PROJECT) return workspace.getRoot(); IPath path = resource.getFullPath(); //modifying the project description may cause linked resources to be created or deleted if (path.segmentCount() == 2 && path.segment(1).equals(IProjectDescription.DESCRIPTION_FILE_NAME)) return parent(resource); return resource; } Thanks
Change was made in the Resources component.
Thanks. I was reassigning it at the same time as you. I did not look at the package closely enough. This problem seems to have been caused by the change in bug#: 127562
Can you paste in the full stack? Someone must be doing a beginRule or workspace.run with only the project as a scheduling rule. You are correct that this was caused by the fix for bug 127562, but that fix was needed and clients that are well behaved should not be affected.
I will paste the full stack at the end. We are the ones defining the project as the Scheduling rule. Would it really make sense for us to lock the entire workspace root during a lengthy checkout process? Our current code in question looks like this: Platform.getJobManager().beginRule(localFolders[i], monitor); Where the referenced item is the project being checked out. Any change we make would have to work correctly on Eclipse 3.0. java.lang.IllegalArgumentException: Attempted to beginRule: R/, does not match outer scope rule: P/SimpleJava at org.eclipse.core.runtime.Assert.isLegal(Assert.java:58) at org.eclipse.core.internal.jobs.ThreadJob.illegalPush(ThreadJob.java:116) at org.eclipse.core.internal.jobs.ThreadJob.push(ThreadJob.java:225) at org.eclipse.core.internal.jobs.ImplicitJobs.begin(ImplicitJobs.java:58) at org.eclipse.core.internal.jobs.JobManager.beginRule(JobManager.java:218) at org.eclipse.core.internal.resources.WorkManager.checkIn(WorkManager.java:96) at org.eclipse.core.internal.resources.Workspace.prepareOperation(Workspace.java:1681) at org.eclipse.core.internal.resources.Project.open(Project.java:832) at org.eclipse.core.internal.resources.Project.open(Project.java:890) at org.tigris.subversion.subclipse.core.commands.CheckoutCommand.basicRun(CheckoutCommand.java:116) at org.tigris.subversion.subclipse.core.commands.CheckoutCommand$1.run(CheckoutCommand.java:210) at org.tigris.subversion.subclipse.core.SVNProviderPlugin$6.run(SVNProviderPlugin.java:441) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1733) at org.tigris.subversion.subclipse.core.SVNProviderPlugin.run(SVNProviderPlugin.java:436) at org.tigris.subversion.subclipse.core.commands.CheckoutCommand.run(CheckoutCommand.java:208) at org.tigris.subversion.subclipse.ui.operations.CheckoutAsProjectOperation.execute(CheckoutAsProjectOperation.java:60) at org.tigris.subversion.subclipse.ui.operations.CheckoutAsProjectOperation.execute(CheckoutAsProjectOperation.java:45) at org.tigris.subversion.subclipse.ui.operations.SVNOperation.run(SVNOperation.java:90) at org.eclipse.team.internal.ui.actions.JobRunnableContext.run(JobRunnableContext.java:144) at org.eclipse.team.internal.ui.actions.JobRunnableContext$ResourceJob.runInWorkspace(JobRunnableContext.java:72) at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:38) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58)
There's an open enhancement to improve this: bug 128709. CC yourself on that bug, which we are considering for M6. What you really should be doing is using the ResourceRuleFactory. This would insulate you from hard-coding a specific scheduling rule, and allow us to change the rule in the future. For opening project p, you would use ISchedulingRule rule = IWorkspace.getRuleFactory().modifyRule(p); And then do: IWorkspace.run(runnable, rule, 0, null), or IJobManager.beginRule(rule);
(In reply to comment #5) > There's an open enhancement to improve this: bug 128709. CC yourself on that > bug, which we are considering for M6. > > What you really should be doing is using the ResourceRuleFactory. This would > insulate you from hard-coding a specific scheduling rule, and allow us to > change the rule in the future. For opening project p, you would use > > ISchedulingRule rule = IWorkspace.getRuleFactory().modifyRule(p); > > And then do: IWorkspace.run(runnable, rule, 0, null), or > IJobManager.beginRule(rule); While I can see where it would make sense to use this code for getting the rules it would still have undesirable side effects. For example, calling modifyRule() for he project is now going to lock the entire workspace during the checkout. That is not acceptable, we might as well have a modal dialog up if we are going to do that. An openRule() would not really help because we cannot use that in Eclipse 3.0 code unless we stick with hard coding the rules. Our TeamProvider class has a getRuleFactory() method. Is there some way we can provide our own subclassed ResourceRuleFactory that would restore the previous behavior? It doesn't seem so as I do not see where IProject#open will use it. Couldn't you potentially go back and solve the original problem by introducing a new rule that is called when setting the project description?
OK, I am experimenting with doing it the way you suggested. This certainly makes it all work correctly as expected. What I am looking for is side-effects of locking the workspace. Now I am a bit confused by what I am seeing. Basically, with this change, I am seeing what I expected. I can start a checkout and put it in the background. I can then open and edit a Java file while it is running, but when I try to save I am locked up until it finishes. Here is where I get confused. I see the same behavior in Eclipse 3.0, with our without this change. If we were locking the project with our rule in that version, shouldn't I have been able to edit and save source in an unrelated project? As it stands now, I will probably just commit the change to work the way you suggested but I am not understanding why this was not working the way I thought it was before.
> Couldn't you potentially go back and solve the original problem by introducing > a new rule that is called when setting the project description? I considered this, but it would be a breaking change, because setDescription says it uses modifyRule. I.e., a well behaved client will likely do (this is pseudo-code): ISchedulingRule rule = factory.modifyRule(project); try { beginRule(rule); project.setDescription(...); } finally { endRule(rule); } This is roughly what was happening in bug 127562. If modifyRule() returns the project, this code may fail.
Re: comment #7 - it depends on what scheduling rule the editor save code is using. If the editor save code locks the workspace, then it won't run concurrently with checkout no matter what rule you use. This may have been the case in 3.0 - I don't remember.
I'm going to mark this is as a dup for openRule request. *** This bug has been marked as a duplicate of 128709 ***
