You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by "Frank Budinsky (JIRA)" <tu...@ws.apache.org> on 2007/05/14 17:37:16 UTC

[jira] Created: (TUSCANY-1283) Better organization of the interfaces and classes in the SDO Java project

Better organization of the interfaces and classes in the SDO Java project
-------------------------------------------------------------------------

                 Key: TUSCANY-1283
                 URL: https://issues.apache.org/jira/browse/TUSCANY-1283
             Project: Tuscany
          Issue Type: Improvement
          Components: Java SDO Implementation
            Reporter: Frank Budinsky
             Fix For: Java-SDO-Mx


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.

We have 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, clients that are only using standard SDO APIs, SDOUtil, and XMLStreamHelper, should be unaffected by the reorganization 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 plan:

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.sdo.util (deprecated)
	SDOUtil (deprecated - clients should switch to org.apache.tuscany.sdo.api.SDOUtil)

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


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org


Re: [jira] Created: (TUSCANY-1283) Better organization of the interfaces and classes in the SDO Java project

Posted by ant elder <an...@gmail.com>.
Kind of related to this JIRA, could the spec/sdo-api module be moved in the
SVN repo from tuscany/java/spec/sdo-api to tuscany/java/sdo/api?

   ...ant

On 5/14/07, Frank Budinsky (JIRA) <tu...@ws.apache.org> wrote:
>
> Better organization of the interfaces and classes in the SDO Java project
> -------------------------------------------------------------------------
>
>                  Key: TUSCANY-1283
>                  URL: https://issues.apache.org/jira/browse/TUSCANY-1283
>              Project: Tuscany
>           Issue Type: Improvement
>           Components: Java SDO Implementation
>             Reporter: Frank Budinsky
>              Fix For: Java-SDO-Mx
>
>
> 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.
>
> We have 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, clients that are only using standard SDO APIs, SDOUtil, and
> XMLStreamHelper, should be unaffected by the reorganization 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 plan:
>
> 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.sdo.util (deprecated)
>         SDOUtil (deprecated - clients should switch to
> org.apache.tuscany.sdo.api.SDOUtil)
>
> package org.apache.tuscany.sdo.helper (deprecated)
>         XMLStreamHelper (deprecated - clients should switch to
> org.apache.tuscany.sdo.api.XMLStreamHelper)
>
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>

[jira] Updated: (TUSCANY-1283) Better organization of the interfaces and classes in the SDO Java project

Posted by "Amita Vadhavkar (JIRA)" <tu...@ws.apache.org>.
     [ https://issues.apache.org/jira/browse/TUSCANY-1283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Amita Vadhavkar updated TUSCANY-1283:
-------------------------------------

    Fix Version/s:     (was: Java-SDO-Next)
                   Java-SDO-1.1

> Better organization of the interfaces and classes in the SDO Java project
> -------------------------------------------------------------------------
>
>                 Key: TUSCANY-1283
>                 URL: https://issues.apache.org/jira/browse/TUSCANY-1283
>             Project: Tuscany
>          Issue Type: Improvement
>          Components: Java SDO Implementation
>            Reporter: Frank Budinsky
>             Fix For: Java-SDO-1.1
>
>
> 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.
> We have 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, clients that are only using standard SDO APIs, SDOUtil, and XMLStreamHelper, should be unaffected by the reorganization 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 plan:
> 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.sdo.util (deprecated)
> 	SDOUtil (deprecated - clients should switch to org.apache.tuscany.sdo.api.SDOUtil)
> package org.apache.tuscany.sdo.helper (deprecated)
> 	XMLStreamHelper (deprecated - clients should switch to org.apache.tuscany.sdo.api.XMLStreamHelper)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org


[jira] Resolved: (TUSCANY-1283) Better organization of the interfaces and classes in the SDO Java project

Posted by "Kelvin Goodson (JIRA)" <tu...@ws.apache.org>.
     [ https://issues.apache.org/jira/browse/TUSCANY-1283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kelvin Goodson resolved TUSCANY-1283.
-------------------------------------

    Resolution: Fixed

The basis of the plan described above is in place.  The split between emf  and non-emf runtime was implemented by an additional project, rather than a division at the java package level.

> Better organization of the interfaces and classes in the SDO Java project
> -------------------------------------------------------------------------
>
>                 Key: TUSCANY-1283
>                 URL: https://issues.apache.org/jira/browse/TUSCANY-1283
>             Project: Tuscany
>          Issue Type: Improvement
>          Components: Java SDO Implementation
>            Reporter: Frank Budinsky
>             Fix For: Java-SDO-Next
>
>
> 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.
> We have 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, clients that are only using standard SDO APIs, SDOUtil, and XMLStreamHelper, should be unaffected by the reorganization 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 plan:
> 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.sdo.util (deprecated)
> 	SDOUtil (deprecated - clients should switch to org.apache.tuscany.sdo.api.SDOUtil)
> package org.apache.tuscany.sdo.helper (deprecated)
> 	XMLStreamHelper (deprecated - clients should switch to org.apache.tuscany.sdo.api.XMLStreamHelper)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org