I don’t want to be a pain, but I do want to mention that this change broke us too. Our break was a little more subtle though. Our server classpath container was not getting populated. It turned out that the old resolveClasspathContainer(IRuntime,String) method is no longer being called. It has been deprecated and replaced with the new resolveClasspathContainer(IRuntime) method, whose default implementation returns an empty array. Easy enough fix, but it took a bit of digging to figure this out.
Konstantin
BEA Systems
From: wtp-dev-bounces@xxxxxxxxxxx [mailto:wtp-dev-bounces@xxxxxxxxxxx] On Behalf Of John Arthorne
Sent: Thursday, January 26, 2006 11:40 AM
To: General discussion of project-wide or architectural issues.
Subject: Re: [wtp-dev] API change in 1.0.1?
Note that this kind of change does not break binary compatibility, so even though Igor's plugin now has compile errors in its source it would continue to run on 1.0.1 if compiled against 1.0.0. Igor just needs to ensure when he builds his plugin against 1.0.1 to set up his plugin version prerequisites accordingly. Having said that, it has always been the practice in the Eclipse SDK to never add API in a maintenance release (although it did happen in the past in some critical cases). Plugins from a maintenance release should generally be completely interchangeable with plugins from the base release, and adding API indicates this isn't the case. If WTP isn't following this practice, I suggest at least publishing a list of (non-breaking) API changes in the maintenance release release notes or migration guide to make life easier for adopters and plugin writers.
John
Timothy Deboer/Toronto/IBM@IBMCA
Sent by: wtp-dev-bounces@xxxxxxxxxxx 26/01/2006 09:57 AM Please respond to
"General discussion of project-wide or architectural issues." |
| To | "General discussion of project-wide or architectural issues." <wtp-dev@xxxxxxxxxxx> | cc | | Subject | Re: [wtp-dev] API change in 1.0.1? |
|
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)
deboer@xxxxxxxxxx
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
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev
_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev
