You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@tuscany.apache.org by "Millies, Sebastian" <Se...@ids-scheer.com> on 2010/10/04 17:47:45 UTC

[SDO] Raw types in generated coding from XSD2JavaGenerator

Hello there,

how much work would it be to make the org.apache.tuscany.sdo.generate.XSD2JavaGenerator
generate interfaces and implementations with proper generic types, instead of
raw types? For example, for an xsd containing the fragment

<complexType name="MappingRuleType">
    <sequence>
      <element name="extendSelection" type="mappingrule:ExtendSelectionType"
        maxOccurs="unbounded" minOccurs="0">
      </element>
    </sequence>
</complexType>    

I would desire the corresponding interface to expose the method
	List<ExtendSelectionType> getExtendSelection();

instead of
	List getExtendSelection();

I am using Tuscany 1.6. Has this tool been adapted for Tuscany 2.0?
Or is there a particular reason why raw types are generated? 

Sebastian Millies


Re: [SDO] Raw types in generated coding from XSD2JavaGenerator

Posted by Simon Laws <si...@googlemail.com>.
On Mon, Oct 4, 2010 at 4:47 PM, Millies, Sebastian
<Se...@ids-scheer.com> wrote:
> Hello there,
>
> how much work would it be to make the org.apache.tuscany.sdo.generate.XSD2JavaGenerator
> generate interfaces and implementations with proper generic types, instead of
> raw types? For example, for an xsd containing the fragment
>
> <complexType name="MappingRuleType">
>    <sequence>
>      <element name="extendSelection" type="mappingrule:ExtendSelectionType"
>        maxOccurs="unbounded" minOccurs="0">
>      </element>
>    </sequence>
> </complexType>
>
> I would desire the corresponding interface to expose the method
>        List<ExtendSelectionType> getExtendSelection();
>
> instead of
>        List getExtendSelection();
>
> I am using Tuscany 1.6. Has this tool been adapted for Tuscany 2.0?
> Or is there a particular reason why raw types are generated?
>
> Sebastian Millies
>
>

Hi Sebastien

I think it generates Java in the way that it does to be compliant with
the SDO 2.1 spec [1] which I'm told still supports java 1.4. Having
said that I noticed some commits recently to upgrade the version of
EMF we're on so that may have Java version implications. I think Ant
committed that so any ideas what minimum support level for Java we're
on for SDO trunk?

We haven't done anything specifically in the SDO code base to support
Tuscany SCA 2.x as far as I'm aware.

[1] http://osoa.org/display/Main/Service+Data+Objects+Specifications

Regards

Simon

-- 
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com