[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [wtp-dev] Action required for adopters of org.eclipse.wst.wsdl for WTP 3.1 M5

We chose not to increase the major version in the org.eclipse.wst.wsdl plugin because we did not make any API changes in the plugin.  javax.wsdl introduced new API, which the wst.wsdl plugin uses.  During my testing, I found that even though clients were using our existing API, they could run into compile errors like:
The type javax.wsdl.extensions.AttributeExtensible cannot be resolved. It is indirectly referenced from required .class files
(AttributeExtensible being new API in javax.wsdl)

And if there were no compile errors, there was still the possibility of runtime errors depending on how they used our wsdl model.  And that's why I recommended bumping up the lower bound together.

Amy Wu
905.413.2522, T/L 313-2522

David Carver <dcarver@xxxxxxxxxxxxxxxx>
Sent by: wtp-dev-bounces@xxxxxxxxxxx

01/14/2009 02:33 PM

Please respond to
"General discussion of project-wide or architectural issues."        <wtp-dev@xxxxxxxxxxx>

"General discussion of project-wide or architectural issues." <wtp-dev@xxxxxxxxxxx>
Re: [wtp-dev] Action required for adopters of        org.eclipse.wst.wsdl        for        WTP 3.1 M5

Amy Wu wrote:
> Sure, people can go ahead and widen their ranges now to prevent build
> breakage.  But I would advise soon after the wsdl changes are released
> (I'll notify the mailing list when this happens), the lower bound
> tightens up again.  If by some fluke, someone has only
> org.eclipse.wst.wsdl 1.2.0 & javax.wsdl 1.4.1, they may run into errors.
I don't necessarily see that as an issue, if the new version is still
backwards compatible with the old version, and they are only using API's
that existing in 1.2 and 1.4.1, those same APIs should exist in the new
versions as well, otherwise it's a major version change.   I would go as
far to set the upper bound to 2.0 in both cases, but I'm more liberal
that way.


wtp-dev mailing list