Summary: | (Missing) Transitive dependancy and quickfix failing silently. | ||
---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Sebastian Scheid <mypurchase> |
Component: | Core | Assignee: | Jerome Lanneluc <jerome_lanneluc> |
Status: | RESOLVED DUPLICATE | QA Contact: | |
Severity: | normal | ||
Priority: | P3 | CC: | daniel_megert, markus.kell.r, martinae, wassim.melhem |
Version: | 3.2.1 | ||
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Whiteboard: |
Description
Sebastian Scheid
2006-11-12 16:42:08 EST
In your scenario, the problem would have been avoided if B re-exported its dependency on A. This should be done whenever a plug-in (ie. B) exposes API from another plug-in (ie. A) to a client (ie. C). This way C would have gotten all of A's types on its classpath for free without an explicitly dependency on A. It's B's responsibility to make sure its clients (ie. C) don't have to go through the production you went through. I am not sure what quickfix you are referring, but I assume it's coming from JDT/UI. Moving there to comment on whether there is a problem in that area or not. This is not a quickfix issue however, this is a design issue that people exposing APIs (ie. B) should be aware of. You're not the first one with this problem, it's really tricky to find out that your classpath misses some classes used in a classfile you use. This is the scenario: - project A, requires project B public class A extends B { // error on A: 'A' must implement inherited method 'bar' // no error on B } - project B, requires C public abstract class B { public abstract I bar(); } - project C: public interface I { } The quick fix can't find method 'bar' in the AST and can't do anything. Question to jdt.core. Shouldn't there be an warning on the reference to B saying that B requires I? I think that would be most helpful to the user. It would be better to not show the quick fix here, but for this we would need such a warning. Or we fix the fact that 'bar is not in the AST... But I think for the suer it would be better to learn about the classpath problem as early as possible. From Kent (in bug 176118): Jerome - Can o.e.jdt.internal.core.SearchableEnvironment & NameLookup find binary types instead of source types in cases like this one ? (In reply to comment #3) > Jerome - Can o.e.jdt.internal.core.SearchableEnvironment & NameLookup find > binary types instead of source types in cases like this one ? Unfortunatley we cannot find binary types because: - the Java model is source based - the workspace might not be built I agree that if autobuild is on, we could use the output of other projects, but this is a complete change in direction. Wassim, why don't you add project A on the buildpath of C with a **/* forbidden access rule ? This would prevent code in C to use types in A but this would make types in A available to our search environment and this solves this particular issue. several reasons: 1. forbidden severity is customizable, which is not good. Classes from A should not be directly accessible from C under any circumstance. 2. Project A appears on the classpath of C in the UI, implying that it is there at runtime, which is not true. So while stuffing the classpath to keep the type hierarchy/search for jdt/core intact is something to consider wrt this problem, I don't want to open a whole can of worms with people seeing/using stuff that won't be there at runtime. Sounds like the same problem as bug 73957 and bug 148844. *** This bug has been marked as a duplicate of bug 148844 *** |