Community
Participate
Working Groups
Created attachment 279706 [details] stack trace While attempting to run junit tests from context menu, they were not getting launched throwing the attached stack trace. On second attempt they do get launched. Steps to reproduce 1. clone http://git.eclipse.org/c/platform/eclipse.platform.swt.git/tree/tests into local machine using git 2. Launch eclipse with fresh workspace 3. Import org.eclipse.swt.tests project using import->Existing projects into workspace 4. Run http://git.eclipse.org/c/platform/eclipse.platform.swt.git/tree/tests/org.eclipse.swt.tests/JUnit%20Tests/org/eclipse/swt/tests/junit/AllTests.java as junit test Junit tests do not get launched here throwing attached stack trace in error log. If you try again they do get launched
Looks like a problem with debug launch trying to build with a wrong rule.
Sravan, can you provide the exact steps? Also which build and is it a regression compared to 4.12?
(In reply to Dani Megert from comment #2) > Sravan, can you provide the exact steps? Also which build and is it a > regression compared to 4.12? Build Info: eclipse.buildId=4.13.0.I20190828-1800 java.version=12.0.2 java.vendor=AdoptOpenJDK BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=en_US Command-line arguments: -os linux -ws gtk -arch x86_64 I will try and get a simpler use case and update the bug.
(In reply to Andrey Loskutov from comment #1) > Looks like a problem with debug launch trying to build with a wrong rule. I will check but not aware of any rule change for Project build. @Michael, Do you remember any change from Job rule perspective?
(In reply to Sarika Sinha from comment #4) > (In reply to Andrey Loskutov from comment #1) > > Looks like a problem with debug launch trying to build with a wrong rule. > > I will check but not aware of any rule change for Project build. I have no IDE at hand right now, so this was my first guess. Usually the build job takes the "right" rule for the resources to be built, therefore my assumption was that we made some mistake in debug launcher and run this task in a job with incompatible "outer" rule.
However you're right, the message is strange, the build job uses empty? multi-rule: "Attempted to beginRule: MultiRule[], does not match outer scope rule: R/". What? In which case build manager computes an empty rule for building? Simeon, can you please check? I can't remember that we changed something related in resources, but who knows, may be some optimization broke something?
Its a regression from 4.8. I can see this problem from 4.9
> Its a regression from 4.8. I can see this problem from 4.9 So most likely something related to parallel builds then. (In reply to Andrey Loskutov from comment #6) > "Attempted to beginRule: MultiRule[], does not match outer scope rule: R/". > What? In which case build manager computes an empty rule for building? > Simeon, can you please check? I can't remember that we changed something > related in resources, but who knows, may be some optimization broke > something? Yes, the empty multi-rule is a bad smell, especially after a project.build(), the current rule should at least be the current project... Also, another smell about MultiRule is shouldn't an empty multi-rule basically be a match for any other ISchedulingRule (ie empty multirule be equivalent to no rule)?
Created attachment 279714 [details] smaller swt test suite Steps to reproduce 1. Start eclipse any version from 4.9 (Any java version is fine) with new workspace 2. Open error log view 3. Import attached project (you'll see "Attempted to beginRule: MultiRule[], does not match outer scope rule: R/" in the error log) 4. Try to run AllWidgetTests.java as junit test. (it doesn't start and you'll see same error message as step 3 in error log) 5. Try to run the tests again. This time tests will launch
Reproducible on Windows 10 also.
Reproducible on Mac 10.14
Andrey, our rule problems were due to a workspace residing in a git repository. This doesn't seem to be the case here. Builders with empty rules that I see so far: * org.eclipse.pde.internal.core.builders.ManifestConsistencyChecker (when building) * org.eclipse.pde.internal.core.builders.ExtensionPointSchemaBuilder (when running the JUnit test and when building) For the ManifestConsistencyChecker, the rule is returned due to: org.eclipse.pde.internal.core.builders.ManifestConsistencyChecker.getRule(int, Map<String, String>) @Override public ISchedulingRule getRule(int kind, Map<String, String> args) { return new MultiRule(Arrays.stream(getProject().getWorkspace().getRoot().getProjects()) .filter(PDEBuilderHelper::isPDEProject).toArray(ISchedulingRule[]::new)); } For the ExtensionPointSchemaBuilder, similar code in org.eclipse.pde.internal.core.builders.ExtensionPointSchemaBuilder.getRule(int, Map<String, String>): @Override public ISchedulingRule getRule(int kind, Map<String, String> args) { return new MultiRule(Arrays.stream(getProject().getWorkspace().getRoot().getProjects()) .filter(PDEBuilderHelper::isPDEProject) .toArray(ISchedulingRule[]::new)); } isPDEProject implementation: return project != null && project.isAccessible() && (PDE.hasPluginNature(project) || PDE.hasFeatureNature(project) || PDE.hasUpdateSiteNature(project)); The attached project has only 1 nature: <natures> <nature>org.eclipse.jdt.core.javanature</nature> </natures> But has builders: <buildCommand> <name>org.eclipse.jdt.core.javabuilder</name> <arguments> </arguments> </buildCommand> <buildCommand> <name>org.eclipse.pde.ManifestBuilder</name> <arguments> </arguments> </buildCommand> <buildCommand> <name>org.eclipse.pde.SchemaBuilder</name> <arguments> </arguments> </buildCommand> I'm guessing, not nice that PDE behaves poorly in such situations, but the attached project seems to be misconfigured, so not really PDE to blame?
> Its a regression from 4.8. I can see this problem from 4.9 So most likely something related to parallel builds then (that's demonstrated later by Simeon) (In reply to Andrey Loskutov from comment #6) > "Attempted to beginRule: MultiRule[], does not match outer scope rule: R/". > What? In which case build manager computes an empty rule for building? > Simeon, can you please check? I can't remember that we changed something > related in resources, but who knows, may be some optimization broke > something? Yes, the empty multi-rule is a bad smell, especially after a project.build(), the current rule should at least be the current project... Also, another smell about MultiRule is shouldn't an empty multi-rule basically be a match for any other ISchedulingRule (ie empty multirule be equivalent to no rule)? (In reply to Simeon Andreev from comment #12) > * org.eclipse.pde.internal.core.builders.ManifestConsistencyChecker (when > building) > * org.eclipse.pde.internal.core.builders.ExtensionPointSchemaBuilder (when > running the JUnit test and when building) > [...] > > @Override > public ISchedulingRule getRule(int kind, Map<String, String> args) { > return new > MultiRule(*somePossibleEmptyStream*.toArray(ISchedulingRule[]::new)); > } > > I'm guessing, not nice that PDE behaves poorly in such situations Right, the builders should probably return either null or getProject() as scheduling rule in that case. > but the > attached project seems to be misconfigured, so not really PDE to blame? The project indeed seems misconfigured, so while PDE is to blame, I don't think it's worth the trouble of fixing it in RC2.
Moving to PDE based on the comments.
What's the status here? Please don't make this a ping-pong match.
Thanks Simeon Andreev. I investigated this and found the same conclusion. The project is grossly misconfigured. It has PDE builders but no pde nature. Either PDE builders should be removed or PDE nature should be added. How did project end up in this state? Trying to fix something in a project with inconsistent state doesn't make any sense. Closing this as invalid !
