[jira] Issue Comment Edited: (QPID-524) Common GenTool

["Kim van der Riet (JIRA)" <qp...@incubator.apache.org>]

    [ https://issues.apache.org/jira/browse/QPID-524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12506230 ] 

Kim van der Riet edited comment on QPID-524 at 6/20/07 4:31 AM:
----------------------------------------------------------------

Agreed - there should be one generator (whatever form it takes) capable of handling the AMQP version differences or all our target languages. For the record, here are the version change use cases that were handled by the generator (except where noted as new or future) - since the generator has no test of its own, it is possible that subsequent changes may have broken some of these... In all of the examples below, v.1, v.2 and v.3 refer to arbitrary but increasing versions of the AMQP specification to be supported in a particular build:

The following differences between *any number* of AMQP versions must be detected and handled by the code generator:

1. In "top-level" (<amqp> level) model:
1.1 Change in <constant> value attributes;
1.2 [New for 0-10] For constants of class field-table-type, changes to any attribute except label between constants of the same name.
1.3 Addition of new constant(s)
1.4 Deletion of constant(s)

Example:
v.1:
   <constant name="c1" value="1" />
   <constant name="c2" value="2" />
   <constant name="c3" value="3" />
 
v.2:
   <constant name="c1" value="10" />  <!-- 1.1 -->
   <constant name="c4" value="4" />     <!-- 1.3, 1.4 -->
   <constant name="c3" value="3" />

v.3:
   <constant name="c1" value="100" />  <!-- 1.1 -->
   <constant name="c4" value="4" />
   <constant name="c5" value="5" />  <!-- 1.3, 1.4 -->

1.5 Change in type attributes between domains of the same name;
1.6 Addition of new domain(s);
1.7 Deletion of domain(s);
1.8 Change in definition of underlying domain;
1.9 [Future] Change in <assert> elements that are contained within a domain if these are used in any code-generation capacity (for instance, <assert check="notnull"/> would be easy to handle).

Example:
v.1:
   <domain name="uuid" type="uuid" />
   <domain name="method-id" type="uuid" />

v.2:
   <domain name="uuid" type="shortstr" />   <!-- 1.5 -->
   <domain name="method-id" type="uuid" />  <!-- 1.8 -->


1.10 Addition of new classes;
1.11 Deletion of classes;
1.12 Changes to the index of classes of the same name (including reusing previous version values or interchanging indecies of two classes from one version to the next);

Example:
v.1:
   <class name="A" index="100" />
   <class name="B" index="110" />
   <class name="C" index="120" />
	     
v.2:
   <class name="A" index="120" />	<!-- 1.12 -->
   <class name="C" index="110" /> 	<!-- 1.11, 1.12 -->
   <class name="D" index="130" /> 	<!-- 1.10 -->

2. In each class:
2.1 Changes to the <chassis> element(s) of a class;
2.2 Changes to the <field> element(s) of a class;
2.3 Addition of <field> element(s) to a class;
2.4 Deletion of <field> element(s) from a class;
2.5 Changes to the <method> element(s) of a class;
2.6 Addition of <method> element(s) to a class;
2.7 Deletion of <method> element(s) from a class;
2.8 Changes to the index of a method within a class (including reusing previous version values or interchanging indecies of two methods from one version to the next);

Example:
v.1:
   <class name="A">
      <chassis name="server" />
      <field name="f1" domain="d1" />
      <field name="f2" domain="d2" />
      <field name="f3" domain="d3" />
      <method name="m1" index="10" />
      <method name="m2" index="20" />
      <method name="m3" index="30" />
      <method name="m4" index="40" />
   </class>
	     
v.2:
   <class name="A">
      <chassis name="server" />
      <chassis name="client" />			<!-- 2.1 -->
      <field name="f1" domain="d1" />
      <field name="f2" domain="d5" />		<!-- 2.2 -->
      <field name="f4" domain="d4" />      <!-- 2.3, 2.4 -->
      <method name="m1" index="10" />
      <method name="m2" index="30" />		<!-- 2.8 -->
      <method name="m3" index="20" />		<!-- 2.8 -->
      <method name="m5" index="50" />		<!-- 2.6, 2.7 -->
   </class>

3. Methods:
3.1 Changes to the <chassis> element(s) of a method;
3.2 Changes to the domain attribute of the <field> element(s) of a method, especially if these involve bit fields which are packed;
3.3 Addition of <field> element(s) to a method;
3.4 Deletion of <field> element(s) from a method;
3.5 Changes to the position (ordinal number) of a field within a method (including interchanging two fields from one verion to the next), especially if these involve bit fields which are packed.

Example:
v.1:
   <method name="m1">
      <chassis name="server" />
      <field name="f1" domain="d1" />
      <field name="f2" domain="d2" />
      <field name="f3" domain="d3" />
      <field name="f4" domain="d4" />
   </method>

v.2:
   <method name="m1">
      <chassis name="client" />			<!-- 3.1 -->
      <field name="f1" domain="d1" />
      <field name="f3" domain="d3" />      <!-- 3.5 -->
      <field name="f2" domain="d1" />      <!-- 3.5, 3.2 -->
      <field name="f4" domain="d4" />
      <field name="f5" domain="d5" />		<!-- 3.3 -->
   </method>
	 
v.3:
   <method name="m1">
      <chassis name="client" />
      <chassis name="server" />
      <field name="f1" domain="d1" />
      <field name="f2" domain="d1" />      <!-- 3.5 -->
      <field name="f3" domain="d3" />      <!-- 3.5 -->
      <field name="f5" domain="d5" />		<!-- 3.4 -->
   </method>

4. Fields:
4.1 [Future] Change in <assert> elements that are contained within a field if these are used in any code-generation capacity (for instance, <assert check="notnull"/> would be easy to handle).


> Common GenTool
> --------------
>
>                 Key: QPID-524
>                 URL: https://issues.apache.org/jira/browse/QPID-524
>             Project: Qpid
>          Issue Type: Improvement
>          Components: Code Generator
>    Affects Versions: M3
>            Reporter: Arnaud Simon
>            Priority: Minor
>
> I have found out that Gentool is in a kind of a mess currently. That is to say
> that: 
> - Java uses the common Gentool but the templates are located in the java projects instead of being hosted by the Gentool project (a bit of re-factoring would be need there)  
> - .Net does not use it yet but uses the old saxon8 way :( 
> - Cpp hosts its own version of it. 
> Java, Cpp and .Net should use the same Gentool. The cpp project uses its own version because the current version does not support versionning. So, we may have to rethink the global architecture of Gentool. But however it would be good to only maintain a single common GenTool. 

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