Anything that is within the internal package should not be covered by deprecation. It's in the docs and the support guys are aware of it. Anything public can change through normal deprecation rules.

This works for other projects, so I'm not sure why we need to make special rules. XTS is different in that there is no standard API for it to conform to, but I assume it's still using the internal/mwlabs approach so the above still applies.

The trouble with listing interfaces/classes is that it's fairly arbitrary. Do we take only what we use in the AS? What about when running stand-alone? What about JTS or any of the extensions we have to the various standards?

So I'd prefer that we stick with the .internal. and use the deprecation rules (which don't prevent changes that are incompatible with previous releases, but in a controlled manner.)

This works for other projects, so I'm not sure why we need to make special rules. XTS is different in that there is no standard API for it to conform to, but I assume it's still using the internal/mwlabs approach so the above still applies.

"adinn" wrote:

This works for other projects, so I'm not sure why we need to make special rules. XTS is different in that there is no standard API for it to conform to, but I assume it's still using the internal/mwlabs approach so the above still applies.

Err, well, not exactly -- we currently "expose" just the tip of the iceberg. i.e. we have split the deployed code into an "api" jar plus a set of "interna"l jars culled from the sar, WSAS, WSCF, WS-C, WS-T and WSTX components (ok, it's a little more messy but . . .). This split is only conventional -- all the jars are present in the deployed service archive but only one of them has 'api' in the name. The intention is that we install a copy of this jar in the AS client directory for users to compile against.

The API jar only contains the (very) small number of classes required for AT and BA client code to compile correctly,-- not just the UserTX//BA and TX/BAManager classes but also ancillary classes like Vote, SystemException etc.

This also happens to be the exact same set of classes which comprise the API documented in the User Guide. There is no reason why a straight AT/BA client should ever need to look under the hood at what is contained in the internal jars.

Of course this does not mean that someone cannot actually look under the hood. But there is very little incentive to do this with XTS.

It does not provide any extensibility mechanisms for the benefit of XTS clients on a par with, for example, the LockManager or StateManager classes implemented by ArjunaCore. I agree we should proceed by deprecating public classes/methods in these internal jars

but I'd be surprised if anyone who was not implementing an extension to the XTS package ever needed to build on this code (e.g.perhaps the SOA platform guys might need to open them up).

BTW in terms of XTS, mwlabs == internal

Where does it say 'no deprecation' in the CP rules? Certainly no breaking backward compatibility if it can be avoided, but there are times when changes need to be made to fix bugs and they do break backwards compatibility. But then backwards compatibility with a bug is something we don't want.