Hi Igor,
I understand your concern and am sorry I broke your implementation, but I don't see any way to avoid a problem like this. I followed the Eclipse API guidelines even though this class is not API yet and carefully evolved an abstract class by adding a new concrete method. There is just about no way that I could predict that the method name or signature might already be used by an external implementor.
Jeffrey - Future possibility for v2 of the API scanning tool? To avoid this we would need to have all WTP users produce a scan that includes all of the method signatures that they have when extending classes and interfaces from WTP.
Tim deBoer
WebSphere Tools - IBM Canada Ltd.
(905) 413-3503 (tieline 969)
[EMAIL PROTECTED]
| Igor Fedorenko <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED] 26/01/2006 09:37 AM
|
|
Hi,
I just noticed that new public method
resolveClasspathContainer(IRuntime) has been added to
org.eclipse.jst.server.core.RuntimeClasspathProviderDelegate in 1.0.1
M-builds. Because of this change my Tomcat plugin does not compile any
more (it happens to have protected method with the same signature). Not
too difficult to fix, but should not M-builds be 100% API compatible
with the release?
--
Regards,
Igor Fedorenko
_______________________________________________
wtp-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/wtp-dev
_______________________________________________ wtp-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/wtp-dev
