group-interface, imbricated groups doesn't render correct interfaces

[cr0man]

First of all, congratulations for writing this plugin. It is really helpful, however I think I run into an issue that made me stop using it. Sorry for not being able to provide a full project describing the problem, but I will try to describe as much as possible here.

Consider this fragment of schema (full schema is available here http://www.aixm.aero/public/standard_page/download.html):

    <complexType name="AirportSuppliesServiceTimeSliceType">
        <complexContent>
            <extension base="aixm:AbstractAIXMTimeSliceType">
                <sequence>
                    <group ref="aixm:AirportSuppliesServicePropertyGroup"/>
                    <element name="extension" minOccurs="0" maxOccurs="unbounded">
                        <complexType>
                            <choice>
                                <element ref="aixm:AbstractAirportSuppliesServiceExtension"/>
                                <element ref="aixm:AbstractAirportGroundServiceExtension"/>
                                <element ref="aixm:AbstractServiceExtension"/>
                            </choice>
                            <attributeGroup ref="gml:OwnershipAttributeGroup"/>
                        </complexType>
                    </element>
                </sequence>
            </extension>
        </complexContent>
    </complexType>
    <group name="AirportSuppliesServicePropertyGroup">
        <sequence>
            <group ref="aixm:AirportGroundServicePropertyGroup" minOccurs="0"/>
            <element name="fuelSupply" type="aixm:FuelPropertyType" nillable="true" minOccurs="0" maxOccurs="unbounded"/>
            <element name="oilSupply" type="aixm:OilPropertyType" nillable="true" minOccurs="0" maxOccurs="unbounded"/>
            <element name="nitrogenSupply" type="aixm:NitrogenPropertyType" nillable="true" minOccurs="0" maxOccurs="unbounded"/>
            <element name="oxygenSupply" type="aixm:OxygenPropertyType" nillable="true" minOccurs="0" maxOccurs="unbounded"/>
        </sequence>
    </group>
    <group name="AirportGroundServicePropertyGroup">
        <sequence>
            <group ref="aixm:ServicePropertyGroup" minOccurs="0"/>
            <element name="airportHeliport" type="aixm:AirportHeliportPropertyType" nillable="true" minOccurs="0" maxOccurs="unbounded"/>
        </sequence>
    </group>
    <group name="ServicePropertyGroup">
        <sequence>
            <element name="flightOperations" type="aixm:CodeFlightDestinationType" nillable="true" minOccurs="0"/>
            <element name="rank" type="aixm:CodeFacilityRankingType" nillable="true" minOccurs="0"/>
            <element name="compliantICAO" type="aixm:CodeYesNoType" nillable="true" minOccurs="0"/>
            <element name="name" type="aixm:TextNameType" nillable="true" minOccurs="0"/>
            <element name="location" type="aixm:ElevatedPointPropertyType" nillable="true" minOccurs="0"/>
            <element name="serviceProvider" type="aixm:UnitPropertyType" nillable="true" minOccurs="0"/>
            <element name="call-sign" type="aixm:CallsignDetailPropertyType" nillable="true" minOccurs="0" maxOccurs="unbounded"/>
            <element name="radioCommunication" type="aixm:RadioCommunicationChannelPropertyType" nillable="true" minOccurs="0" maxOccurs="unbounded"/>
            <element name="groundCommunication" type="aixm:ContactInformationPropertyType" nillable="true" minOccurs="0" maxOccurs="unbounded"/>
            <element name="availability" type="aixm:ServiceOperationalStatusPropertyType" nillable="true" minOccurs="0" maxOccurs="unbounded"/>
            <element name="annotation" type="aixm:NotePropertyType" nillable="true" minOccurs="0" maxOccurs="unbounded"/>
        </sequence>
    </group>

Take a look at the groups: AirportSuppliesServicePropertyGroup, AirportGroundServicePropertyGroup, ServicePropertyGroup.

What the plugin generates (version 1.2.2 and 1.3.0) is:

class AirportSuppliesServiceTimeSliceType extends AbstractAIXMTimeSliceType implements AirportSuppliesServicePropertyGroup, OwnershipAttributeGroup

with all fields and corresponding methods defined in the schema.

interface AirportSuppliesServicePropertyGroup extends AirportGroundServicePropertyGroup;

with getter and setters according to AirportSuppliesServicePropertyGroup schema.

interface AirportGroundServicePropertyGroup extends ServicePropertyGroup;

with no getters and setters

interface ServicePropertyGroup;

with no getters and setters

It seems that group-interface works only on the first level of groups.

[mklemm]

Thank you very much for reporting this issue! I'll have a look into it, and I think I know why this is. Because the plugin uses the already generated code model of the classes using the group to determine the correct format of the getters and setters, if a group isn't directly used in a complexType definition, no getters or setters will be generated for it. As a workaround, try adding a complexType DIRECTLY referencing the groups "ServicePropertyGroup" and "AirportGroundServicePropertyGroup", and see whether the interfaces are generated correctly in this case. This issue is already documented in the README file, but I haven't found a cleaner solution for it yet. The main reason why I did it this way are other possible plug-ins somewhere in the plugin chain of the XJC. They might modify method signatures etc. and might not be aware of my plugin. So, the safest solution was to simply "copy back" the method signatures of setXXX and getXXX from the already generated implementing classes. However, if there are no complexTypes referencing the group directly, an implementation cannot be found. Hope I could help you! Mirko

[mklemm]

Now, the plan for resolving this is:

• Search multiple levels of group references for usages of the group in a complexType
• If references can be found, use the implementations of the getters and setters in the interface
• if none can be found, generate the getters and setters via a default pattern.

[cr0man]

I will be happy to test the solution when is implemented.

[mklemm]

Hi, could you please let me know if the workaround works for you? Maybe it’s a different issue…

Mirko

Am 2014-11-07 um 11:01 schrieb cr0man notifications@github.com:

I will be happy to test the solution when is implemented.

— Reply to this email directly or view it on GitHub.

[mklemm]

The issue has been resolved now in release 1.3.6