Summary: | [testsources] Exclude test code more aggressively | ||
---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Stephan Herrmann <stephan.herrmann> |
Component: | Core | Assignee: | JDT-Core-Inbox <jdt-core-inbox> |
Status: | NEW --- | QA Contact: | |
Severity: | normal | ||
Priority: | P3 | ||
Version: | 4.9 | ||
Target Milestone: | --- | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | stalebug |
Description
Stephan Herrmann
2018-10-18 06:32:27 EDT
As Stephan referenced this in bug 544017, some thoughts: So far, test class path is excluded for main code during compilation and e.g. completion. The Java model and refactorings always use the full classpath including test dependencies. Pre Java 9 this should not really hurt, as no additional errors are to be expected by seeing more classes. But with Java 9 it may lead to errors if packages become split packages because of this, especially if the unnamed module is involved. Actually I'm not sure if these internally existing, but non-visible errors lead to any visible defects in any tools. Maybe the right classes are still resolved, even if the package is a split package? Anyway, e.g. CompilationUnitResolver.resolve has multiple overloads. In two of them, a CancelableNameEnvironment is constructed, currently always with excludeTestCode=false. The first one talks a simple ICompilationUnit. If we add the necessary info to it, we could set the flag depending on the source folder: org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(ICompilationUnit, IJavaProject, List, NodeSearcher, Map, WorkingCopyOwner, int, IProgressMonitor) The other one takes an array of ICompilationUnit[]. Let's assume they are a mixture of test code and main code. I'm not sure if using two instances of CancelableNameEnvironment here would work at all (if test compilation units reference main compilation units), so probably we'd be back to the current state, where we just use the full classpath for all of them. (But we could probably set excludeTestCode correctly if all of them are either main or test code). So an actual use case where a defect can be seen would be good. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. |