Hi,

I'd like to start better organizing the interfaces and classes in the SDO 
Java project. Currently, there is no clean separation between client API 
vs. implementation (internal) classes. There's also no separation between 
the EMF-dependent and independent parts of the RT.

I believe most of you know that we've been recommending clients stick to 
standard SDO APIs (from the spec) and for anything else use class SDOUtil, 
which is where we put all the required extensions that people have 
requested. One other interface, XMLStreamHelper (for working with StAX 
streams) is the only other interface in Tuscany that clients are expected 
to use directly.

So, if you are only using standard SDO APIs, SDOUtil, and XMLStreamHelper, 
you should be unaffected for now, because we will keep deprecated versions 
of SDOUtil and XMLStreamHelper around for a while, but we would like to 
move them to a better package and have clients gradually move to the new 
ones.

Here is the concrete proposal:

package org.apache.tuscany.sdo.api (all client API will be under this 
package)
        SDOUtil (new one)
        XMLStreamHelper (new one)
        other new things ...

package org.apache.tuscany.sdo.rtemf (EMF-based runtime implementation 
classes)
        subset of existing classes (most of them) that have EMF 
dependencies
        (these are existing packages just moved down one level, e.g., 
org.apache.tuscany.sdo.helper -> org.apache.sdo.tuscany.sdo.rtemf.helper)

package org.apache.tuscany.sdo.rtlib (common runtime implementation 
classes)
        subset of existing classes that have no EMF dependencies

package org.apache.tuscany.util (deprecated)
        SDOUtil (deprecated - clients should switch to 
org.apache.tuscany.sdo.api.SDOUtil)

package org.apache.tuscany.helper (deprecated)
        XMLStreamHelper (deprecated - clients should switch to 
org.apache.tuscany.sdo.api.XMLStreamHelper)

Please let me know if you have any comments or concerns. Also please speak 
up if anybody has other classes that they would like us to keep deprecated 
versions of, to give you time to move.

Thanks,
Frank.


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to