Summary: | Eclipse Compiler needs a compile dependency to a plug-in, but javac does not need that dependency | ||||||
---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Ulli Hafner <Knut.Friedhelm> | ||||
Component: | Core | Assignee: | Kent Johnson <kent_johnson> | ||||
Status: | VERIFIED FIXED | QA Contact: | |||||
Severity: | blocker | ||||||
Priority: | P3 | CC: | markus.kell.r, Olivier_Thomann | ||||
Version: | 3.5 | Flags: | Olivier_Thomann:
review+
|
||||
Target Milestone: | 3.5 RC1 | ||||||
Hardware: | All | ||||||
OS: | Windows XP | ||||||
Whiteboard: | |||||||
Attachments: |
|
Description
Ulli Hafner
2009-05-08 11:19:34 EDT
"But this dependency shouldn't be required. otherwise a plugin would need all transitive dependencies of all parent classes..." Actually that is exactly what it means. The compiler needs to check more issues with Java 5 semantics that require walking up a type's hierarchy. Likely the same as bug 269883 What is the definition of the methods mock() & raiseChangedEvent() ? Hmm, but shouldn't Eclipse be smart enough to traverse the dependency tree on its own without having an explicit dependency? Otherwise Eclipse and OSGi can't be used in projects that have more than a couple of dependencies. We compile our plug-ins with maven 2 as build tool and javac as compiler: here we don't have problems and don't need these dependencies. E.g., if you have a small project with one dependency to library A and that library has dependencies to libraries 1-100 then with Eclipse 3.5M7 I need to add all these dependencies to my plug-in? How do you handle that manually? Even more, if the owner of library A decides to add additional dependencies, then I also need to manually add these! This will not work in practice. Here some more details: /** * Creates mock object of given class or interface. * <p> * See examples in javadoc for {@link Mockito} class * * @param classToMock class or interface to mock * @return mock object */ public static <T> T mock(Class<T> classToMock) { return mock(classToMock, null, null, RETURNS_DEFAULTS); } /** * Raises an event to denote that the specified object has been changed * (with respect to the associations of the object). All registered * listeners are notified about this change in the UI thread. The changed * object is available in method {@link PropertyChangeEvent#getNewValue()}. * * @param object * the changed object */ void raiseChangedEvent(final DBObject object); Created attachment 135668 [details] Proposed patch This patch changes the fix for bug 206930 We no longer will force the hierarchy of every parameter type to be resolved for an exact method match to proceed in 1.5. Instead we will check to see if the parameter type's hierarchy has been connected, if not we will look for all possible method matches. In a full build case, this won't cause a performance issue since all source types are connected before method sends are resolved. Olivier - please review Patch looks good. +1 Fix released for 3.5RC1 To verify use the AmbiguousMethodTest tests added as part of 206930 Ulli - could please try the latest RC1 build as soon as possible to see if this fixes your problem thx Verified with RC1: I20090515-1143. This change caused problems and will be reverted, see bug 460993. The fix for bug 360164 actually fixed this problem in a better way. |