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
|
Igor Fedorenko
<igorfie@xxxxxxxxx>
Sent by: wtp-dev-bounces@xxxxxxxxxxx
26/01/2006 09:37 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
|
[wtp-dev] API change in 1.0.1?
|
|
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
