ODF Toolkit
  1. ODF Toolkit
  2. ODFTOOLKIT-60

Update ODF 1.2 schema to OpenDocument-v1.2-cd05-rev02-schema

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: simple-odfdom-0.8
    • Fix Version/s: odfdom-0.9
    • Component/s: codegen
    • Labels:
      None
    • Environment:
      Operating System: All
      Platform: All

      Description

      A new ODF 1.2 draft has been published by the ODF TC (see http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office#odf12 ).

      The codegeneration should be updated to the new RelaxNG schema.

      1. ASF.LICENSE.NOT.GRANTED--91-intermediate-source-generation20100806.zip
        147 kB
        Svante Schubert
      2. ASF.LICENSE.NOT.GRANTED--91-odf-schema-update20101115.zip
        93 kB
        Svante Schubert
      3. ASF.LICENSE.NOT.GRANTED--91-schema-update--two-patches.zip
        220 kB
        Svante Schubert
      4. ASF.LICENSE.NOT.GRANTED--91-update-odf12-rev02-schema.patch
        1.67 MB
        Svante Schubert
      5. ASF.LICENSE.NOT.GRANTED--91-update-odf12-rev02-schema-devRep.patch
        1.13 MB
        Svante Schubert
      6. ASF.LICENSE.NOT.GRANTED--bug91-devin-20100818.patch
        27 kB
        devin
      7. ASF.LICENSE.NOT.GRANTED--bug91-devin-20100819.patch
        2 kB
        devin
      8. ASF.LICENSE.NOT.GRANTED--bug91-devin-20100823.patch
        15 kB
        devin
      9. ASF.LICENSE.NOT.GRANTED--bug91-generator-20100825.patch
        47 kB
        devin
      10. ASF.LICENSE.NOT.GRANTED--bug91-generator-20100907.patch
        49 kB
        devin
      11. ASF.LICENSE.NOT.GRANTED--bug91-generator-20100908.patch
        50 kB
        devin
      12. ASF.LICENSE.NOT.GRANTED--bug91-generator-20100909.patch
        52 kB
        devin
      13. ASF.LICENSE.NOT.GRANTED--bug91-ODF12-update.zip
        1.04 MB
        Svante Schubert
      14. ASF.LICENSE.NOT.GRANTED--bug91-odfdom-20100906.rar
        556 kB
        devin
      15. ASF.LICENSE.NOT.GRANTED--bug91-odfdom-20100908.rar
        553 kB
        devin
      16. ASF.LICENSE.NOT.GRANTED--bug91-odfdom-20100909-no-generated-sources.patch
        1.32 MB
        Svante Schubert
      17. ASF.LICENSE.NOT.GRANTED--bug91-odfdom-20100909-with-generated-sources.zip
        1.05 MB
        Svante Schubert
      18. ASF.LICENSE.NOT.GRANTED--bug91-odfdom without generated sources.patch
        1.86 MB
        devin
      19. ASF.LICENSE.NOT.GRANTED--bug91-schema-update-2810.patch
        73 kB
        Svante Schubert
      20. ASF.LICENSE.NOT.GRANTED--bug91-vm.patch
        1.91 MB
        devin

        Issue Links

          Activity

          Hide
          Svante Schubert added a comment -

          Received the latest schema from Michael Brauer and will update the sources hopefully later this day, after the integration of #85, #99 and #100.

          Show
          Svante Schubert added a comment - Received the latest schema from Michael Brauer and will update the sources hopefully later this day, after the integration of #85, #99 and #100.
          Hide
          Svante Schubert added a comment -

          Adapted title to correct RelaxNG schema version,
          ie. 'OpenDocument-schema-v1.2-cd03-rev02'

          Show
          Svante Schubert added a comment - Adapted title to correct RelaxNG schema version, ie. 'OpenDocument-schema-v1.2-cd03-rev02'
          Hide
          Svante Schubert added a comment -

          Created an attachment (id=141)
          New schema applied, source generated..

          Please review, further JavaDoc changes might follow in separate JavaDoc issue.
          It would be nice to have a JavaDoc package.html for every Java package to get the overview.html filled with information (always the first two sentences are being taken).

          Show
          Svante Schubert added a comment - Created an attachment (id=141) New schema applied, source generated.. Please review, further JavaDoc changes might follow in separate JavaDoc issue. It would be nice to have a JavaDoc package.html for every Java package to get the overview.html filled with information (always the first two sentences are being taken).
          Hide
          Svante Schubert added a comment -

          Please review and integrate..

          Show
          Svante Schubert added a comment - Please review and integrate..
          Hide
          Svante Schubert added a comment -

          Will fix this for ODFDOM 0.8..
          Svante

          Show
          Svante Schubert added a comment - Will fix this for ODFDOM 0.8.. Svante
          Hide
          Svante Schubert added a comment -
          Show
          Svante Schubert added a comment -
          Hide
          Svante Schubert added a comment -

          Created an attachment (id=182)
          ZIP of #bug91# Updating to latest ODF 1.2 part Community Draft 4

          Hi Daisy,

          This patch includes the updated HTML version and RelaxNG of the 4th community draft of the ODF 1.2 XML Schema and as well the corrected set of default values extracted by an updated XSL stylesheet (bug76).
          I have double checked the default list, went through the list of missing values listed in ODFTOOLKIT-52, looked for unset values and even fixed the XML of the ODF specification itself.

          For reviewing this patch please regenerate the sources with 'mvn -P codegen' as usual.

          For JavaDoc generation you should have as well the latest version of odfdom~taglet checked out, build and delivered to your local repository to get the references from the JavaDoc to the updated spec right.

          I tested the JavaDoc generation and the links from our generated attribute, datatype and element JavaDoc classes to the new HTML specification.

          Best regards,
          Svante

          Show
          Svante Schubert added a comment - Created an attachment (id=182) ZIP of #bug91# Updating to latest ODF 1.2 part Community Draft 4 Hi Daisy, This patch includes the updated HTML version and RelaxNG of the 4th community draft of the ODF 1.2 XML Schema and as well the corrected set of default values extracted by an updated XSL stylesheet (bug76). I have double checked the default list, went through the list of missing values listed in ODFTOOLKIT-52 , looked for unset values and even fixed the XML of the ODF specification itself. For reviewing this patch please regenerate the sources with 'mvn -P codegen' as usual. For JavaDoc generation you should have as well the latest version of odfdom~taglet checked out, build and delivered to your local repository to get the references from the JavaDoc to the updated spec right. I tested the JavaDoc generation and the links from our generated attribute, datatype and element JavaDoc classes to the new HTML specification. Best regards, Svante
          Hide
          Ying Chun Guo added a comment -

          Thank you Svante. It's a big progress.

          I fixed a small java doc warning, and some small java doc flaws.

          Reviewed and pushed.

          Show
          Ying Chun Guo added a comment - Thank you Svante. It's a big progress. I fixed a small java doc warning, and some small java doc flaws. Reviewed and pushed.
          Hide
          Svante Schubert added a comment -

          We should test, if the schema provided for the ODF 1.2 public review differs from the one we are using. If there is a difference, we should regenerate our sources based on the latest schema.

          Show
          Svante Schubert added a comment - We should test, if the schema provided for the ODF 1.2 public review differs from the one we are using. If there is a difference, we should regenerate our sources based on the latest schema.
          Hide
          Svante Schubert added a comment -

          The RelaxNG syntax has been changed in the revision 4, which results in our current code generation library in an exception.

          Another reason to switch to the new source code generator created by my collegue Hans-Peter Schaal.

          Assigned this issue to myself for next release.
          Svante

          Show
          Svante Schubert added a comment - The RelaxNG syntax has been changed in the revision 4, which results in our current code generation library in an exception. Another reason to switch to the new source code generator created by my collegue Hans-Peter Schaal. Assigned this issue to myself for next release. Svante
          Hide
          Svante Schubert added a comment -

          Of course the latest update should be based on ODF 1.2 CD 5

          The complete bundle as an 11MB zip can be found here:
          http://www.oasis-open.org/committees/download.php/38369/OpenDocument-v1.2-cd05.zip

          Show
          Svante Schubert added a comment - Of course the latest update should be based on ODF 1.2 CD 5 The complete bundle as an 11MB zip can be found here: http://www.oasis-open.org/committees/download.php/38369/OpenDocument-v1.2-cd05.zip
          Hide
          Svante Schubert added a comment -

          As discussed an intermediate step for the source code generation.
          My advise, handle the generation as a black box and aim for generating the current sources by only adapting the templates of

          odfdom~schema2template/schema2template/src/main/resources/examples/odf/odfdom-java

          Compare the generated Source output
          odfdom~schema2template/schema2template/target/classes/examples/odf/odfdom-java

          with the existing sources and adapt the templates if necessary. Sometimes there might be a problem int he old sources we have to fix. We do not have to generate existing issues again.

          Intermediate patch comes next..

          Good luck,
          Svante

          Show
          Svante Schubert added a comment - As discussed an intermediate step for the source code generation. My advise, handle the generation as a black box and aim for generating the current sources by only adapting the templates of odfdom~schema2template/schema2template/src/main/resources/examples/odf/odfdom-java Compare the generated Source output odfdom~schema2template/schema2template/target/classes/examples/odf/odfdom-java with the existing sources and adapt the templates if necessary. Sometimes there might be a problem int he old sources we have to fix. We do not have to generate existing issues again. Intermediate patch comes next.. Good luck, Svante
          Hide
          Svante Schubert added a comment -

          Created an attachment (id=361)
          Intermediate patch of ODFTOOLKIT-60 - source code generation

          The patch is attached as ZIP due to its size.
          -Svante

          Show
          Svante Schubert added a comment - Created an attachment (id=361) Intermediate patch of ODFTOOLKIT-60 - source code generation The patch is attached as ZIP due to its size. -Svante
          Hide
          devin added a comment -

          Hi, Svante
          I found some difference between the old dom classes using in ODFDOM and new classes which generated based on your patch. For reference.

          Change List:
          1. initial ELEMENT_NAME
          method OdfName.get replace OdfName.newName, such as,
          NEW: public static final OdfName ELEMENT_NAME = OdfName.get(OdfNamespace.get(OdfNamespaceNames.CHART), "data-point");
          OLD: public static final OdfName ELEMENT_NAME = OdfName.newName(OdfNamespaceNames.CHART, "data-point" );
          2. return type of get**Attribute in Element
          all of the return type is string, which is different from old one. such as,
          NEW: public String getChartRepeatedAttribute() {
          ChartRepeatedAttribute attr = (ChartRepeatedAttribute) getOdfAttribute( OdfName.get( OdfNamespace.get(OdfNamespaceNames.CHART), "repeated" ) );
          if( attr != null )

          { return attr.getValue(); }

          return null;
          }
          OLD: public Integer getChartRepeatedAttribute()
          {
          ChartRepeatedAttribute attr = (ChartRepeatedAttribute) getOdfAttribute( OdfNamespace.newNamespace(OdfNamespaceNames.CHART), "repeated" ) ;
          if( attr != null )

          { return Integer.valueOf( attr.intValue() ); }

          return null;
          }
          3. all of the class has been abstract class.
          such as,
          NEW: public abstract class ChartDataPointElement extends OdfStylableElement
          OLD: public class ChartDataPointElement extends OdfStylableElement
          4. method newTextNode is added in new version.
          such as, in class TextAuthorInitialsElement
          /**

          • Add text content. Only elements which are allowed to have text content offer this method.
            */
            public void newTextNode(String content)
            Unknown macro: { if (content != null && !content.equals("")) { this.appendChild(this.getOwnerDocument().createTextNode(content)); } }

            5. method newTextNode is removed in new version.
            such as, in class TextBookmarkElement
            /**

          • Initialization of the mandatory attributes of {@link TextBookmarkElement}

            *

          • @param textNameAttributeValue The mandatory attribute {@odf.attribute text:name}

            "
            *
            */
            public void init(String textNameAttributeValue)

            { setTextNameAttribute( textNameAttributeValue ); }

            6. classes lost in element package
            OdfStylableElement, OdfStyleableShapeElement, OdfStyleBase and OdfStylePropertiesBase
            these classes may be not generated automatically.
            7. attribute class method isId(), return value changed
            such as, in class XmlIdAttribute
            NEW: public boolean isId()

            { return false; }

            OLD: public boolean isId()

            { return true; }

            8. all of the classes in style package lost, we should write a new vm file for them.
            9. class OdfStyleFamily should be locate in style package
            10. class import declaration order and method declaration order are changed, but have no influence for using.

          Devin

          Show
          devin added a comment - Hi, Svante I found some difference between the old dom classes using in ODFDOM and new classes which generated based on your patch. For reference. Change List: 1. initial ELEMENT_NAME method OdfName.get replace OdfName.newName, such as, NEW: public static final OdfName ELEMENT_NAME = OdfName.get(OdfNamespace.get(OdfNamespaceNames.CHART), "data-point"); OLD: public static final OdfName ELEMENT_NAME = OdfName.newName(OdfNamespaceNames.CHART, "data-point" ); 2. return type of get**Attribute in Element all of the return type is string, which is different from old one. such as, NEW: public String getChartRepeatedAttribute() { ChartRepeatedAttribute attr = (ChartRepeatedAttribute) getOdfAttribute( OdfName.get( OdfNamespace.get(OdfNamespaceNames.CHART), "repeated" ) ); if( attr != null ) { return attr.getValue(); } return null; } OLD: public Integer getChartRepeatedAttribute() { ChartRepeatedAttribute attr = (ChartRepeatedAttribute) getOdfAttribute( OdfNamespace.newNamespace(OdfNamespaceNames.CHART), "repeated" ) ; if( attr != null ) { return Integer.valueOf( attr.intValue() ); } return null; } 3. all of the class has been abstract class. such as, NEW: public abstract class ChartDataPointElement extends OdfStylableElement OLD: public class ChartDataPointElement extends OdfStylableElement 4. method newTextNode is added in new version. such as, in class TextAuthorInitialsElement /** Add text content. Only elements which are allowed to have text content offer this method. */ public void newTextNode(String content) Unknown macro: { if (content != null && !content.equals("")) { this.appendChild(this.getOwnerDocument().createTextNode(content)); } } 5. method newTextNode is removed in new version. such as, in class TextBookmarkElement /** Initialization of the mandatory attributes of {@link TextBookmarkElement} * @param textNameAttributeValue The mandatory attribute {@odf.attribute text:name} " * */ public void init(String textNameAttributeValue) { setTextNameAttribute( textNameAttributeValue ); } 6. classes lost in element package OdfStylableElement, OdfStyleableShapeElement, OdfStyleBase and OdfStylePropertiesBase these classes may be not generated automatically. 7. attribute class method isId(), return value changed such as, in class XmlIdAttribute NEW: public boolean isId() { return false; } OLD: public boolean isId() { return true; } 8. all of the classes in style package lost, we should write a new vm file for them. 9. class OdfStyleFamily should be locate in style package 10. class import declaration order and method declaration order are changed, but have no influence for using. Devin
          Hide
          devin added a comment -

          Created an attachment (id=365)
          bug91 patch based on Svante's

          Hi, Svante
          This patch is based on yours.
          I modified some VM file contents and format all of them using Veloeclipse( http://veloeclipse.googlecode.com/svn/trunk/update/).
          Now, most of the attribute class have been consistant with the old one.

          You can continue your work based on mine.
          Have a nice weekend
          Devin

          Show
          devin added a comment - Created an attachment (id=365) bug91 patch based on Svante's Hi, Svante This patch is based on yours. I modified some VM file contents and format all of them using Veloeclipse( http://veloeclipse.googlecode.com/svn/trunk/update/ ). Now, most of the attribute class have been consistant with the old one. You can continue your work based on mine. Have a nice weekend Devin
          Hide
          Svante Schubert added a comment -

          Hi Devin,

          I wondered why your patch was 10times bigger, the reason was you did based it on latest revision.
          Took the time to separated your files from the previous one and pushed your changes after review to the master.

          To keep it easier for the reviewer, we should both only patch those files we have changed.
          Thanks for the update so far.
          Svante

          Show
          Svante Schubert added a comment - Hi Devin, I wondered why your patch was 10times bigger, the reason was you did based it on latest revision. Took the time to separated your files from the previous one and pushed your changes after review to the master. To keep it easier for the reviewer, we should both only patch those files we have changed. Thanks for the update so far. Svante
          Hide
          devin added a comment -

          Created an attachment (id=370)
          bug91 patch 20100818

          Hi,Svante

          This is an intermediate patch, the following issues are included:
          1) fix the strange indentation problem.
          2) add default value declaration for element.
          3) add data type information for get/set attribute method in element.
          4) add enum declaration for some enum attribute in element.
          A problem need to disscussion:
          The method public PuzzlePieceSet getDatatypes() in PuzzlePiece seems doesn't work.
          the returns are always null. Do you encounter the sam problem, Svante?

          Devin

          Show
          devin added a comment - Created an attachment (id=370) bug91 patch 20100818 Hi,Svante This is an intermediate patch, the following issues are included: 1) fix the strange indentation problem. 2) add default value declaration for element. 3) add data type information for get/set attribute method in element. 4) add enum declaration for some enum attribute in element. A problem need to disscussion: The method public PuzzlePieceSet getDatatypes() in PuzzlePiece seems doesn't work. the returns are always null. Do you encounter the sam problem, Svante? Devin
          Hide
          Svante Schubert added a comment -

          Hi Devin,

          thanks for the upate. You are making good progress.

          First let me answer your question:
          You mentioned one method "public PuzzlePieceSet getDatatypes()" in PuzzlePiece always returns null.
          If 'always' means for the element template you been working on, it is normal as elements do not have datatypes, only attributes do have.

          I did a review on your changes:
          Perhaps you are already beyond the first milestone - creation of all generated source of ODFDOM as close as they exist in ODFDOM.
          The idea I had previous in mind, was to make a diff (e.g. via totalcommander and easily see if something is missing).

          But after the review of some elements I realized that the order of the generated methods might change and we would have problems in comparison anyway.
          Nevertheless the less we add in new features now, the less changes we will see.

          I noticed the following enhancements from you to generated elements:
          1) Removed the init() method in favor of the constructor, it seems a good idea from my current perspective
          2) As the default value and the value set differs from the parent, you added those constants and enums to the element.
          Here I would favor to add both to the attributes as it seems to be more object oriented (both belong to the attribute).
          For instance the default value I would sugggest to access the default value by getDefault() method. We might still adapt it to getDefaultValue() later.
          Still I would drop this for our first step, the similar sources is sufficient.
          (comment it out in the template for now).

          3) To test, just copy the generated element sources into the latest odfdom repository, exchanging the existing one. You will notice the compile errors left to fix.

          Note: Small changes in brackets will lead to changes, when in doubt generate the brackets as they would be created after formatting the source code by the IDE.

          To complete the first milestone (this issue), we need to adapt the templates of all generated sources & the Maven integration, so the sources will be generated by odfdom "mvn -P codegen" similar as they are generated today.

          Pushed your intermediate changes.

          Thanks,
          Svante

          Show
          Svante Schubert added a comment - Hi Devin, thanks for the upate. You are making good progress. First let me answer your question: You mentioned one method "public PuzzlePieceSet getDatatypes()" in PuzzlePiece always returns null. If 'always' means for the element template you been working on, it is normal as elements do not have datatypes, only attributes do have. I did a review on your changes: Perhaps you are already beyond the first milestone - creation of all generated source of ODFDOM as close as they exist in ODFDOM. The idea I had previous in mind, was to make a diff (e.g. via totalcommander and easily see if something is missing). But after the review of some elements I realized that the order of the generated methods might change and we would have problems in comparison anyway. Nevertheless the less we add in new features now, the less changes we will see. I noticed the following enhancements from you to generated elements: 1) Removed the init() method in favor of the constructor, it seems a good idea from my current perspective 2) As the default value and the value set differs from the parent, you added those constants and enums to the element. Here I would favor to add both to the attributes as it seems to be more object oriented (both belong to the attribute). For instance the default value I would sugggest to access the default value by getDefault() method. We might still adapt it to getDefaultValue() later. Still I would drop this for our first step, the similar sources is sufficient. (comment it out in the template for now). 3) To test, just copy the generated element sources into the latest odfdom repository, exchanging the existing one. You will notice the compile errors left to fix. Note: Small changes in brackets will lead to changes, when in doubt generate the brackets as they would be created after formatting the source code by the IDE. To complete the first milestone (this issue), we need to adapt the templates of all generated sources & the Maven integration, so the sources will be generated by odfdom "mvn -P codegen" similar as they are generated today. Pushed your intermediate changes. Thanks, Svante
          Hide
          devin added a comment -

          Created an attachment (id=372)
          bug91 patch 20100819

          Hi, Svante

          Thank you for your answer about my datatypes question. You are right, it is normal as elements do not have datatypes, only attributes do have.

          In this patch, I updated the attribute template. Not many modifications, only improve the indent and exception catch statement to let the new generation code more similar to the old one.
          Now , from my side, I don't have more update to do on template files. You can take over and update them as your need, such style template. While I will do the parallel work - Maven integration as your arrangement

          Pls review this patch.

          Best regards,
          Devin

          Show
          devin added a comment - Created an attachment (id=372) bug91 patch 20100819 Hi, Svante Thank you for your answer about my datatypes question. You are right, it is normal as elements do not have datatypes, only attributes do have. In this patch, I updated the attribute template. Not many modifications, only improve the indent and exception catch statement to let the new generation code more similar to the old one. Now , from my side, I don't have more update to do on template files. You can take over and update them as your need, such style template. While I will do the parallel work - Maven integration as your arrangement Pls review this patch. Best regards, Devin
          Hide
          Svante Schubert added a comment -

          Thanks for the update, note that you patch from yesterday generates element classes that are not compilable. You might want to adapt the element template first to make the new sources compile.
          To test overwrite the existing sources with the generated sources and run maven (build & unit tests).

          Show
          Svante Schubert added a comment - Thanks for the update, note that you patch from yesterday generates element classes that are not compilable. You might want to adapt the element template first to make the new sources compile. To test overwrite the existing sources with the generated sources and run maven (build & unit tests).
          Hide
          devin added a comment -

          Created an attachment (id=375)
          bug91 patch 20100823

          Hi, Svante
          This is a new intermidiate path.
          In this patch, I have realized the maven plugin integration of code generator. After this patch pushed, we can improve vm files directly in ODFDOM project, which make mistakes fixed more easily. I set four arguments for this plugin:
          (1)targetRoot point out where is the location of generation code.
          (2)resourceRoot point out where is the location of vm files.
          (3)schemaFile point out where is the location of odf schema file.
          (4)configFile point out where is the location of config.xml file.
          The following is the pom.xml configuration sample:
          <profile>
          <id>codegen</id>
          <build>
          <defaultGoal>install</defaultGoal>
          <plugins>
          <plugin>
          <groupId>org.odftoolkit</groupId>
          <artifactId>schema2template-maven-plugin</artifactId>
          <version>0.8.6-SNAPSHOT</version>
          <executions>
          <execution>
          <id>dom</id>
          <phase>generate-sources</phase>
          <goals>
          <goal>codegen</goal>
          </goals>
          <!-- DOM LAYER CONFIGURATION -->
          <configuration>
          <targetRoot>$

          {basedir}/src/main/java/</targetRoot>
          <resourceRoot>${basedir}

          /src/codegen/new/resources/dom/template</resourceRoot>
          <schemaFile>$

          {basedir}/src/codegen/new/resources/dom/OpenDocument-schema-v1.2-cd04.rng</schemaFile>
          <configFile>${basedir}

          /src/codegen/new/resources/dom/config.xml</configFile>
          </configuration>
          </execution>
          </executions>
          </plugin>
          </plugins>
          </build>
          </profile>
          Attribute and output template files' indent imporvement are also included in this patch.

          I will focus on compile errors and move those redundant attributes away from the element after you push this patch.

          pls review.

          Thanks&Regards,
          Devin

          Show
          devin added a comment - Created an attachment (id=375) bug91 patch 20100823 Hi, Svante This is a new intermidiate path. In this patch, I have realized the maven plugin integration of code generator. After this patch pushed, we can improve vm files directly in ODFDOM project, which make mistakes fixed more easily. I set four arguments for this plugin: (1)targetRoot point out where is the location of generation code. (2)resourceRoot point out where is the location of vm files. (3)schemaFile point out where is the location of odf schema file. (4)configFile point out where is the location of config.xml file. The following is the pom.xml configuration sample: <profile> <id>codegen</id> <build> <defaultGoal>install</defaultGoal> <plugins> <plugin> <groupId>org.odftoolkit</groupId> <artifactId>schema2template-maven-plugin</artifactId> <version>0.8.6-SNAPSHOT</version> <executions> <execution> <id>dom</id> <phase>generate-sources</phase> <goals> <goal>codegen</goal> </goals> <!-- DOM LAYER CONFIGURATION --> <configuration> <targetRoot>$ {basedir}/src/main/java/</targetRoot> <resourceRoot>${basedir} /src/codegen/new/resources/dom/template</resourceRoot> <schemaFile>$ {basedir}/src/codegen/new/resources/dom/OpenDocument-schema-v1.2-cd04.rng</schemaFile> <configFile>${basedir} /src/codegen/new/resources/dom/config.xml</configFile> </configuration> </execution> </executions> </plugin> </plugins> </build> </profile> Attribute and output template files' indent imporvement are also included in this patch. I will focus on compile errors and move those redundant attributes away from the element after you push this patch. pls review. Thanks&Regards, Devin
          Hide
          Svante Schubert added a comment -

          Hi Devin,

          we need a second Mercurial patch for the odfdom repository.
          The odfdom~developer patch can only be integrated, if there is no unit test error and no temporary design has been added (e.g. attribute information in the element instead the attribute class). As the odfdom~developer sources have always to be stable.

          The given patch for the schema2template had difficulties to run the Codegen example from the IDE, there was a NullPointerException as the new schema path includes the "schema2template" in its path, which was added by the IDE.
          I have opened the odfdom~schema2template/schema2template opened in my IDE and run the file
          schema2template/src/main/java/schema2template/example/odf/OdfCodegen.java
          How did you called the file without triggering the path problem?

          Therefore in the end you need to provide two patches one for odfdom~developer and odfdom~schema2template. After code generation of odfdom~developer all tests have to run and in addition no temporary design (attributes constants at elements) are allowed, otherwise users might depend on this by accident.

          Thanks for the update, keep up the good work!
          Svante

          Show
          Svante Schubert added a comment - Hi Devin, we need a second Mercurial patch for the odfdom repository. The odfdom~developer patch can only be integrated, if there is no unit test error and no temporary design has been added (e.g. attribute information in the element instead the attribute class). As the odfdom~developer sources have always to be stable. The given patch for the schema2template had difficulties to run the Codegen example from the IDE, there was a NullPointerException as the new schema path includes the "schema2template" in its path, which was added by the IDE. I have opened the odfdom~schema2template/schema2template opened in my IDE and run the file schema2template/src/main/java/schema2template/example/odf/OdfCodegen.java How did you called the file without triggering the path problem? Therefore in the end you need to provide two patches one for odfdom~developer and odfdom~schema2template. After code generation of odfdom~developer all tests have to run and in addition no temporary design (attributes constants at elements) are allowed, otherwise users might depend on this by accident. Thanks for the update, keep up the good work! Svante
          Hide
          devin added a comment -

          Created an attachment (id=381)
          bug91 code generator patch

          Hi, Svante

          This is the newest version of code generator patch. Compared to the former one, I updated all of the VM files to make sure they can work well under newest schema.

          The ODFDOM project path will follow to upload.

          Please review

          Regards,

          Devin

          Show
          devin added a comment - Created an attachment (id=381) bug91 code generator patch Hi, Svante This is the newest version of code generator patch. Compared to the former one, I updated all of the VM files to make sure they can work well under newest schema. The ODFDOM project path will follow to upload. Please review Regards, Devin
          Hide
          devin added a comment -

          Created an attachment (id=382)
          bug91 odfdom patch

          Hi, Svante
          This is the corresponding ODFDOM project patch. ( a rar file)
          (1)I have use the newest schema OpenDocument-v1.2-cd05-schema.rng replace OpenDocument-schema-v1.2-cd04.rng. The generator works fine. There is no compile error or failed test case.
          (2)Besides the existing vm file, I created style properities and style set files to support generating style classes.
          (3)About maven plugin configuration issue. pls reference the former Comment #21.
          (4)You will see, in main and test package, several code updates are done. They are caused by tiny differences between the two generator, not problem. We should ignore.

          Pls review.

          Regards,

          Devin

          Show
          devin added a comment - Created an attachment (id=382) bug91 odfdom patch Hi, Svante This is the corresponding ODFDOM project patch. ( a rar file) (1)I have use the newest schema OpenDocument-v1.2-cd05-schema.rng replace OpenDocument-schema-v1.2-cd04.rng. The generator works fine. There is no compile error or failed test case. (2)Besides the existing vm file, I created style properities and style set files to support generating style classes. (3)About maven plugin configuration issue. pls reference the former Comment #21. (4)You will see, in main and test package, several code updates are done. They are caused by tiny differences between the two generator, not problem. We should ignore. Pls review. Regards, Devin
          Hide
          Svante Schubert added a comment -

          Hi Devin,

          thanks for both patches.

          Unfortunately the NullPointerException mentioned the week before (see #22)
          still occurs.

          Could you please fix it, perhaps add the creation of the files to a regression
          test and I will afterwards start a deeper review.

          Regards,
          Svante

          Show
          Svante Schubert added a comment - Hi Devin, thanks for both patches. Unfortunately the NullPointerException mentioned the week before (see #22) still occurs. Could you please fix it, perhaps add the creation of the files to a regression test and I will afterwards start a deeper review. Regards, Svante
          Hide
          devin added a comment -

          Created an attachment (id=383)
          bug91-generator-20100907

          Hi, Svante

          Sorry I forgot to change the resource path back When I test these codes I directly run class OdfCodegen, in order to find vm resources I added "schema2template
          " before "target". This is the reason that you face NullPointerException.

          Now pls review the newest patch.

          Devin

          Show
          devin added a comment - Created an attachment (id=383) bug91-generator-20100907 Hi, Svante Sorry I forgot to change the resource path back When I test these codes I directly run class OdfCodegen, in order to find vm resources I added "schema2template " before "target". This is the reason that you face NullPointerException. Now pls review the newest patch. Devin
          Hide
          Svante Schubert added a comment -

          Hi Devin,

          this is a very large step ahead. I have seen that you not only adapted the sources to the existing sources, but even were able to fix the source.

          For instance in Attribute you were able to provide now always the correct default values. You used the automated IDE formatting indention, etc.

          In addition I like your statements in an generated element class for adding a child element:

          • Child element is new in Odf 1.2
            *
          • Child element is mandatory.
            *
            Still we might think about a different Syntax, perhaps similar to the JDK
            @since ODF 1.2
            @since ODF 1.1
            On the get/setter of the new element/attribute and on the element/attribute itself.
            Complicated when only the value has been altered, or it was removed and later added.. But we get off-track, those feature might be worth a stand-alone bugzilla task.

          Aside of this great improvements there are still some parts, that you need to revise.
          (Perhaps you add next time some summary, of what you have changed and why you have changed it, so I am not mistaken about the benefits, I oversee.)

          1) Validation of attribute values.
          The discussion about validation is before your time, but Daisy can give you insights about the validation steps we did before.
          Earlier we used our ODFDOM type classes from the Java package
          org.odftoolkit.odfdom.type.
          to validate every input.

          But often the user only wants add a value to an attribute without need of validation, the validation should become an optional step, but not the default.
          This optional handling has not be added to ODFDOM so far.

          Therefore in public void setValue(String attrValue)
          you should write

          super.setValue(attrValue);

          instead of the current new created

          super.setValue(Double.toString(Double.parseDouble(attrValue)));

          Your version will follow with the enabling of optional validation (you might keep the source as comment in the template.
          (similar for other Java primitives and the getValue method)

          2)
          During review I realized, that if we changed in OdfElement
          public OdfAttribute getOdfAttribute(OdfNamespace namespace, String localname)
          to
          public OdfAttribute getOdfAttribute(NamespaceName namespace, String localname)

          Using the interface, we might generate in OdfElement instead of

          getOdfAttribute(OdfNamespace.newNamespace(OdfDocumentNamespace.CHART),"repeated");

          getOdfAttribute(OdfDocumentNamespace.CHART,"repeated");

          making it easier for the user.

          3)
          Shall we return from an element (e.g. AnimAnimateColorElement.java):

          return SmilRestartDefaultAttribute.DEFAULT_VALUE;

          or

          return "inherit";

          I tend to the first, as the redirection will resolved during compile time and there is only one instance of the DEFAULT_VALUE available.
          You have changed this, I do not see the benefit here.

          PS: As I only could make random picks, there might be further obstacles unseen yet... I assume Daisy finished her review on those changes already.

          Best regards,
          Svante

          Show
          Svante Schubert added a comment - Hi Devin, this is a very large step ahead. I have seen that you not only adapted the sources to the existing sources, but even were able to fix the source. For instance in Attribute you were able to provide now always the correct default values. You used the automated IDE formatting indention, etc. In addition I like your statements in an generated element class for adding a child element: Child element is new in Odf 1.2 * Child element is mandatory. * Still we might think about a different Syntax, perhaps similar to the JDK @since ODF 1.2 @since ODF 1.1 On the get/setter of the new element/attribute and on the element/attribute itself. Complicated when only the value has been altered, or it was removed and later added.. But we get off-track, those feature might be worth a stand-alone bugzilla task. Aside of this great improvements there are still some parts, that you need to revise. (Perhaps you add next time some summary, of what you have changed and why you have changed it, so I am not mistaken about the benefits, I oversee.) 1) Validation of attribute values. The discussion about validation is before your time, but Daisy can give you insights about the validation steps we did before. Earlier we used our ODFDOM type classes from the Java package org.odftoolkit.odfdom.type. to validate every input. But often the user only wants add a value to an attribute without need of validation, the validation should become an optional step, but not the default. This optional handling has not be added to ODFDOM so far. Therefore in public void setValue(String attrValue) you should write super.setValue(attrValue); instead of the current new created super.setValue(Double.toString(Double.parseDouble(attrValue))); Your version will follow with the enabling of optional validation (you might keep the source as comment in the template. (similar for other Java primitives and the getValue method) 2) During review I realized, that if we changed in OdfElement public OdfAttribute getOdfAttribute(OdfNamespace namespace, String localname) to public OdfAttribute getOdfAttribute(NamespaceName namespace, String localname) Using the interface, we might generate in OdfElement instead of getOdfAttribute(OdfNamespace.newNamespace(OdfDocumentNamespace.CHART),"repeated"); getOdfAttribute(OdfDocumentNamespace.CHART,"repeated"); making it easier for the user. 3) Shall we return from an element (e.g. AnimAnimateColorElement.java): return SmilRestartDefaultAttribute.DEFAULT_VALUE; or return "inherit"; I tend to the first, as the redirection will resolved during compile time and there is only one instance of the DEFAULT_VALUE available. You have changed this, I do not see the benefit here. PS: As I only could make random picks, there might be further obstacles unseen yet... I assume Daisy finished her review on those changes already. Best regards, Svante
          Hide
          devin added a comment -

          Created an attachment (id=384)
          bug91-generator-20100908

          Hi, Svante

          Thank you for your comment.

          > 1) Validation of attribute values.
          I agree. The new one is much easier to realize.

          >
          > 2)
          > During review I realized, that if we changed in OdfElement
          > public OdfAttribute getOdfAttribute(OdfNamespace namespace, String localname)
          > to
          > public OdfAttribute getOdfAttribute(NamespaceName namespace, String localname)
          >
          I agree. You can update it, then I will update vm files.

          >
          > 3)
          > Shall we return from an element (e.g. AnimAnimateColorElement.java):
          >
          > return SmilRestartDefaultAttribute.DEFAULT_VALUE;
          >
          > or
          >
          > return "inherit";
          >
          I tend to the second, as it is more intelligible and easier to let the user know what is the default value. For Example, they can see the default value of SmilRestartDefaultAttribute is "inherit" directly, no need to go through class SmilRestartDefaultAttribute and find the value of the DEFAULT_VALUE.
          Actually, each of the string constant surrounded with double quotation marks is only one instance in JVM, isn't? So use "inherit" directly will not lead more space and time cost.

          BTW: I suggest you run "mvn -P codegen" and review in odfdom project directly, which will help you find complie errors and understand the relation of class more easily.

          This patch is the update version of code generator.

          Devin

          Show
          devin added a comment - Created an attachment (id=384) bug91-generator-20100908 Hi, Svante Thank you for your comment. > 1) Validation of attribute values. I agree. The new one is much easier to realize. > > 2) > During review I realized, that if we changed in OdfElement > public OdfAttribute getOdfAttribute(OdfNamespace namespace, String localname) > to > public OdfAttribute getOdfAttribute(NamespaceName namespace, String localname) > I agree. You can update it, then I will update vm files. > > 3) > Shall we return from an element (e.g. AnimAnimateColorElement.java): > > return SmilRestartDefaultAttribute.DEFAULT_VALUE; > > or > > return "inherit"; > I tend to the second, as it is more intelligible and easier to let the user know what is the default value. For Example, they can see the default value of SmilRestartDefaultAttribute is "inherit" directly, no need to go through class SmilRestartDefaultAttribute and find the value of the DEFAULT_VALUE. Actually, each of the string constant surrounded with double quotation marks is only one instance in JVM, isn't? So use "inherit" directly will not lead more space and time cost. BTW: I suggest you run "mvn -P codegen" and review in odfdom project directly, which will help you find complie errors and understand the relation of class more easily. This patch is the update version of code generator. Devin
          Hide
          devin added a comment -

          Created an attachment (id=385)
          bug91-odfdom-20100908

          odfdom patch is updated synchronously.

          Show
          devin added a comment - Created an attachment (id=385) bug91-odfdom-20100908 odfdom patch is updated synchronously.
          Hide
          Svante Schubert added a comment -

          Hi Devin,

          I have reviewed in detail the ODFDOM patch.

          1) As we replace the code generation and generate sources on the lastest schema, there is no need of a directory
          odfdom~developer/src/codegen/new/resources/dom
          aside of
          odfdom~developer/src/codegen/resources/dom

          The user would be confused by having two different implementations.
          Adapted the pom.xml.
          No need to have multiple schemas, neither. I removed the rev04 ODF schema.

          2) We need to move the generated
          odfdom~developer/src/codegen/resources/dom/template/output-files.xml
          into an
          odfdom~developer/target subdirectory. Otherwise we will add incendentally this 0.5MB file on next commit after codegen.

          3) The odfdom patch included the new templates, the generated sources and fixed tests.
          Those 17MB where hard to review. Therefore I copied the templates, made a commit and generated the sources over and over, recognizing the problems, where you provided fixes:
          src\main\java\org\odftoolkit\odfdom\doc\OdfPresentationDocument.java
          src\test\java\org\odftoolkit\odfdom\doc\CreateChildrenElementsTest.java

          4)
          public OdfAttribute getOdfAttribute(OdfNamespace namespace, String localname)
          to
          public OdfAttribute getOdfAttribute(NamespaceName namespace, String localname)

          usage had been adapted in both element templates and the element to have the simpler namespace methods in
          src\main\java\org\odftoolkit\odfdom\pkg\OdfElement.java

          (you might have tried this and it failed, a toString() had to be changed in later in calling stack to toURI())

          The total files of my first revision of the patch are:
          M pom.xml
          M src\main\java\org\odftoolkit\odfdom\doc\OdfPresentationDocument.java
          M src\main\java\org\odftoolkit\odfdom\pkg\OdfElement.java
          M src\test\java\org\odftoolkit\odfdom\doc\CreateChildrenElementsTest.java
          A src\codegen\resources\dom\OpenDocument-v1.2-cd05-schema.rng
          A src\codegen\resources\dom\template\copyright.txt
          A src\codegen\resources\dom\template\java-odfdom-attribute-template.vm
          A src\codegen\resources\dom\template\java-odfdom-attribute-visitor.vm
          A src\codegen\resources\dom\template\java-odfdom-element-template.vm
          A src\codegen\resources\dom\template\java-odfdom-element-visitor.vm
          A src\codegen\resources\dom\template\java-odfdom-elementbase-template.vm
          A src\codegen\resources\dom\template\java-odfdom-stylefamily.vm
          A src\codegen\resources\dom\template\java-odfdom-styleproperties.vm
          A src\codegen\resources\dom\template\java-odfdom-styleset.vm
          A src\codegen\resources\dom\template\output-files.vm
          R src\codegen\resources\dom\OpenDocument-schema-v1.2-cd04.rng
          R src\codegen\resources\dom\javacodetemplate.xml

          The second patch inludes two revision, the second including all generated elements and attributes. It would be great if you could extend the first smaller patch, for easier review.

          Two issues remain to pass this patch:
          I) The 500KB config file shall not be generated within the source tree, but in the target directory.

          II) Please ask your tech lead about the default values. They have to be a singleton and shall not be duplicated within the attributes. If the value might be of interest, it should be part of a new Java Comment to be generated - which would be indeed an improvement. Otherwise we waste memory by duplication without benefit at this point.
          This change seems similar to a regression and have to be undone.

          Thanks for your help,
          Svante

          Show
          Svante Schubert added a comment - Hi Devin, I have reviewed in detail the ODFDOM patch. 1) As we replace the code generation and generate sources on the lastest schema, there is no need of a directory odfdom~developer/src/codegen/new/resources/dom aside of odfdom~developer/src/codegen/resources/dom The user would be confused by having two different implementations. Adapted the pom.xml. No need to have multiple schemas, neither. I removed the rev04 ODF schema. 2) We need to move the generated odfdom~developer/src/codegen/resources/dom/template/output-files.xml into an odfdom~developer/target subdirectory. Otherwise we will add incendentally this 0.5MB file on next commit after codegen. 3) The odfdom patch included the new templates, the generated sources and fixed tests. Those 17MB where hard to review. Therefore I copied the templates, made a commit and generated the sources over and over, recognizing the problems, where you provided fixes: src\main\java\org\odftoolkit\odfdom\doc\OdfPresentationDocument.java src\test\java\org\odftoolkit\odfdom\doc\CreateChildrenElementsTest.java 4) public OdfAttribute getOdfAttribute(OdfNamespace namespace, String localname) to public OdfAttribute getOdfAttribute(NamespaceName namespace, String localname) usage had been adapted in both element templates and the element to have the simpler namespace methods in src\main\java\org\odftoolkit\odfdom\pkg\OdfElement.java (you might have tried this and it failed, a toString() had to be changed in later in calling stack to toURI()) The total files of my first revision of the patch are: M pom.xml M src\main\java\org\odftoolkit\odfdom\doc\OdfPresentationDocument.java M src\main\java\org\odftoolkit\odfdom\pkg\OdfElement.java M src\test\java\org\odftoolkit\odfdom\doc\CreateChildrenElementsTest.java A src\codegen\resources\dom\OpenDocument-v1.2-cd05-schema.rng A src\codegen\resources\dom\template\copyright.txt A src\codegen\resources\dom\template\java-odfdom-attribute-template.vm A src\codegen\resources\dom\template\java-odfdom-attribute-visitor.vm A src\codegen\resources\dom\template\java-odfdom-element-template.vm A src\codegen\resources\dom\template\java-odfdom-element-visitor.vm A src\codegen\resources\dom\template\java-odfdom-elementbase-template.vm A src\codegen\resources\dom\template\java-odfdom-stylefamily.vm A src\codegen\resources\dom\template\java-odfdom-styleproperties.vm A src\codegen\resources\dom\template\java-odfdom-styleset.vm A src\codegen\resources\dom\template\output-files.vm R src\codegen\resources\dom\OpenDocument-schema-v1.2-cd04.rng R src\codegen\resources\dom\javacodetemplate.xml The second patch inludes two revision, the second including all generated elements and attributes. It would be great if you could extend the first smaller patch, for easier review. Two issues remain to pass this patch: I) The 500KB config file shall not be generated within the source tree, but in the target directory. II) Please ask your tech lead about the default values. They have to be a singleton and shall not be duplicated within the attributes. If the value might be of interest, it should be part of a new Java Comment to be generated - which would be indeed an improvement. Otherwise we waste memory by duplication without benefit at this point. This change seems similar to a regression and have to be undone. Thanks for your help, Svante
          Hide
          Svante Schubert added a comment -

          Created an attachment (id=386)
          ODFTOOLKIT-60 - odfdom patch without generated sources

          Only a small patch to ease review. The patch comes without the generated sources, a 'mvn -P codegen' have to be executed before the sources compile.

          Show
          Svante Schubert added a comment - Created an attachment (id=386) ODFTOOLKIT-60 - odfdom patch without generated sources Only a small patch to ease review. The patch comes without the generated sources, a 'mvn -P codegen' have to be executed before the sources compile.
          Hide
          Svante Schubert added a comment -

          Created an attachment (id=387)
          ODFTOOLKIT-60 - odfdom patch with generated sources (ZIPPED)

          Show
          Svante Schubert added a comment - Created an attachment (id=387) ODFTOOLKIT-60 - odfdom patch with generated sources (ZIPPED)
          Hide
          devin added a comment -

          Created an attachment (id=388)
          bug91-generator-20100909

          Hi, Svante

          I update the generator patch to make sure that the 500KB config file be generated from the source tree to the target directory.

          Devin

          Show
          devin added a comment - Created an attachment (id=388) bug91-generator-20100909 Hi, Svante I update the generator patch to make sure that the 500KB config file be generated from the source tree to the target directory. Devin
          Hide
          devin added a comment -

          Created an attachment (id=389)
          bug91-odfdom without generated sources 20100909

          Hi, Svante
          Thank you for your patch update and comment.
          1) In order to help you review easier, this patch doesn't contains generated code.
          2) output-files.xml is generated in target directory now.
          3) I add odf1.1 schema file to make the following info generated right
          *

          • Child element is new in Odf 1.2
            *
            The generator need to compare odf1.1 and odf1.2 schema to make sure whether generate it or not.
            4) all of the "DEFAULT_VALUE"s have been returned as your perfer method

          BTW: about the default values, I updated 4) only want to make you happy and push the patch as soon as possible, Svante. Actually, I don't think return "inherit" will lead to create more than one string object in a JVM. Every JVM has its own string buffer to avoid create needless string. The following test will approve I am right.

          public class StringTest {

          public String getDefaultValue1()

          { return "default value"; }

          public String getDefaultValue2() { return "default value"; }

          public static void main(String args[])

          { StringTest o1=new StringTest(); StringTest o2=new StringTest(); StringTest o3=new StringTest(); System.out.println("The same string object:" + ((o1.getDefaultValue1() == o2.getDefaultValue1())==(o2.getDefaultValue1() == o3.getDefaultValue1()))); o1=new StringTest(); o2=new StringTest(); o3=new StringTest(); System.out.println("The same string object:" + ((o1.getDefaultValue2() == o2.getDefaultValue2())==(o2.getDefaultValue2() == o3.getDefaultValue2()))); o1=new StringTest(); o2=new StringTest(); o3=new StringTest(); System.out.println("The same string object:" + ((o1.getDefaultValue1() == o2.getDefaultValue2())==(o2.getDefaultValue1() == o3.getDefaultValue2()))); }

          }

          OutPut:
          The same string object:true
          The same string object:true
          The same string object:true

          The output show that ONLY ONE "default value" was created.

          Anyway, I have modified templated files to generate code as you like. If there is no other issue, pls push this patch

          Regards,
          Devin

          Show
          devin added a comment - Created an attachment (id=389) bug91-odfdom without generated sources 20100909 Hi, Svante Thank you for your patch update and comment. 1) In order to help you review easier, this patch doesn't contains generated code. 2) output-files.xml is generated in target directory now. 3) I add odf1.1 schema file to make the following info generated right * Child element is new in Odf 1.2 * The generator need to compare odf1.1 and odf1.2 schema to make sure whether generate it or not. 4) all of the "DEFAULT_VALUE"s have been returned as your perfer method BTW: about the default values, I updated 4) only want to make you happy and push the patch as soon as possible, Svante. Actually, I don't think return "inherit" will lead to create more than one string object in a JVM. Every JVM has its own string buffer to avoid create needless string. The following test will approve I am right. public class StringTest { public String getDefaultValue1() { return "default value"; } public String getDefaultValue2() { return "default value"; } public static void main(String args[]) { StringTest o1=new StringTest(); StringTest o2=new StringTest(); StringTest o3=new StringTest(); System.out.println("The same string object:" + ((o1.getDefaultValue1() == o2.getDefaultValue1())==(o2.getDefaultValue1() == o3.getDefaultValue1()))); o1=new StringTest(); o2=new StringTest(); o3=new StringTest(); System.out.println("The same string object:" + ((o1.getDefaultValue2() == o2.getDefaultValue2())==(o2.getDefaultValue2() == o3.getDefaultValue2()))); o1=new StringTest(); o2=new StringTest(); o3=new StringTest(); System.out.println("The same string object:" + ((o1.getDefaultValue1() == o2.getDefaultValue2())==(o2.getDefaultValue1() == o3.getDefaultValue2()))); } } OutPut: The same string object:true The same string object:true The same string object:true The output show that ONLY ONE "default value" was created. Anyway, I have modified templated files to generate code as you like. If there is no other issue, pls push this patch Regards, Devin
          Hide
          Svante Schubert added a comment -

          Hi Devin,

          thank you very much for the update. I pushed the patches!! It is a great step for our project.

          The final adjustments I did were

          1) to remove the two templates
          src\codegen\resources\dom\template\java-odfdom-attribute-visitor.vm
          src\codegen\resources\dom\template\java-odfdom-element-visitor.vm

          Which belong to issue 215, yet not pushed, but I updated all templates in the schema2templates example, so they are not lost.

          2) Adjust the templates to JDK default formatting/indent, so I get no changes when I do an automatted reformat in one of the generated files

          Thanks again, Devin!
          Your work was impressive!

          PS: There are still some issues left on code generation, e.g.
          http://odftoolkit.org/bugzilla/show_bug.cgi?id=201

          If we work on these issues and do additional refactoring on the generator, we now have to be careful not to break our source basis. Some regression test is necessary.
          Instead of time consuming generation of all sources and comparing them, a small set of sources would be sufficient that generate in total all variations of the template. Making a binary identical compare with our references.
          Would you agree on such tests?
          And most important would it be able and/or difficult for you to add this to schema2template? Usually I would not have pushed this patch without regression test, but Daisys patch is already in the queue. What you think?

          Regards,
          Svante

          Show
          Svante Schubert added a comment - Hi Devin, thank you very much for the update. I pushed the patches!! It is a great step for our project. The final adjustments I did were 1) to remove the two templates src\codegen\resources\dom\template\java-odfdom-attribute-visitor.vm src\codegen\resources\dom\template\java-odfdom-element-visitor.vm Which belong to issue 215, yet not pushed, but I updated all templates in the schema2templates example, so they are not lost. 2) Adjust the templates to JDK default formatting/indent, so I get no changes when I do an automatted reformat in one of the generated files Thanks again, Devin! Your work was impressive! PS: There are still some issues left on code generation, e.g. http://odftoolkit.org/bugzilla/show_bug.cgi?id=201 If we work on these issues and do additional refactoring on the generator, we now have to be careful not to break our source basis. Some regression test is necessary. Instead of time consuming generation of all sources and comparing them, a small set of sources would be sufficient that generate in total all variations of the template. Making a binary identical compare with our references. Would you agree on such tests? And most important would it be able and/or difficult for you to add this to schema2template? Usually I would not have pushed this patch without regression test, but Daisys patch is already in the queue. What you think? Regards, Svante
          Hide
          devin added a comment -

          Hi, Svante
          Thank you for your adjustments on the patch.
          It is a good point to add regression test for additional refactoring on the generator. But I have no idea how to do it. Could you give more explaination?
          Thanks!

          Devin
          > Hi Devin,
          >
          > thank you very much for the update. I pushed the patches!! It is a great step
          > for our project.
          >
          > The final adjustments I did were
          >
          > 1) to remove the two templates
          > src\codegen\resources\dom\template\java-odfdom-attribute-visitor.vm
          > src\codegen\resources\dom\template\java-odfdom-element-visitor.vm
          >
          > Which belong to issue 215, yet not pushed, but I updated all templates in the
          > schema2templates example, so they are not lost.
          >
          >
          > 2) Adjust the templates to JDK default formatting/indent, so I get no changes
          > when I do an automatted reformat in one of the generated files
          >
          > Thanks again, Devin!
          > Your work was impressive!
          >
          > PS: There are still some issues left on code generation, e.g.
          > http://odftoolkit.org/bugzilla/show_bug.cgi?id=201
          >
          > If we work on these issues and do additional refactoring on the generator, we
          > now have to be careful not to break our source basis. Some regression test is
          > necessary.
          > Instead of time consuming generation of all sources and comparing them, a small
          > set of sources would be sufficient that generate in total all variations of the
          > template. Making a binary identical compare with our references.
          > Would you agree on such tests?
          > And most important would it be able and/or difficult for you to add this to
          > schema2template? Usually I would not have pushed this patch without regression
          > test, but Daisys patch is already in the queue. What you think?
          >
          > Regards,
          > Svante

          Show
          devin added a comment - Hi, Svante Thank you for your adjustments on the patch. It is a good point to add regression test for additional refactoring on the generator. But I have no idea how to do it. Could you give more explaination? Thanks! Devin > Hi Devin, > > thank you very much for the update. I pushed the patches!! It is a great step > for our project. > > The final adjustments I did were > > 1) to remove the two templates > src\codegen\resources\dom\template\java-odfdom-attribute-visitor.vm > src\codegen\resources\dom\template\java-odfdom-element-visitor.vm > > Which belong to issue 215, yet not pushed, but I updated all templates in the > schema2templates example, so they are not lost. > > > 2) Adjust the templates to JDK default formatting/indent, so I get no changes > when I do an automatted reformat in one of the generated files > > Thanks again, Devin! > Your work was impressive! > > PS: There are still some issues left on code generation, e.g. > http://odftoolkit.org/bugzilla/show_bug.cgi?id=201 > > If we work on these issues and do additional refactoring on the generator, we > now have to be careful not to break our source basis. Some regression test is > necessary. > Instead of time consuming generation of all sources and comparing them, a small > set of sources would be sufficient that generate in total all variations of the > template. Making a binary identical compare with our references. > Would you agree on such tests? > And most important would it be able and/or difficult for you to add this to > schema2template? Usually I would not have pushed this patch without regression > test, but Daisys patch is already in the queue. What you think? > > Regards, > Svante
          Hide
          Svante Schubert added a comment -

          The ODF 1.2 changes are not finished yet, yesterday there was again an update of the ODF schema, see http://lists.oasis-open.org/archives/office/201011/msg00446.html.

          This issue will be reopened to apply changes to
          odfdom~schema2template and
          odfdom~developer

          Show
          Svante Schubert added a comment - The ODF 1.2 changes are not finished yet, yesterday there was again an update of the ODF schema, see http://lists.oasis-open.org/archives/office/201011/msg00446.html . This issue will be reopened to apply changes to odfdom~schema2template and odfdom~developer
          Hide
          Svante Schubert added a comment -

          Created an attachment (id=426)
          Update of the odfdom~schema2template repository

          Show
          Svante Schubert added a comment - Created an attachment (id=426) Update of the odfdom~schema2template repository
          Hide
          Svante Schubert added a comment -

          Created an attachment (id=427)
          Update of the odfdom~developer repository

          This patch comes with two change sets.
          1) The first only contains the changed RNG schema files and pom.xml
          2) The second contains the changed generated files

          Show
          Svante Schubert added a comment - Created an attachment (id=427) Update of the odfdom~developer repository This patch comes with two change sets. 1) The first only contains the changed RNG schema files and pom.xml 2) The second contains the changed generated files
          Hide
          Svante Schubert added a comment -

          Created an attachment (id=433)
          ZIP containing two patches adding .hgeol (see 161) and new ODF RelaxNG to odfdom~schema2template and odfdom~developer

          When I created the new files under Windows, I noticed that all files are flagged as changed. This made the review of changes difficult under Windows.

          The reason therefore was that all files where created in UNIX line ending.

          In order to see in Mercurial 'hg status' only those files with content changes, I made this document dependent of ODFTOOLKIT-99 and added to the .hgignore the suffix of the Velocity templates file.

          By doing so the templates within
          src\codegen\resources\dom\template
          are checked out according the platform.

          This patch is similar to the previous two patches with two difference:
          1) They are based on the patches of issue #161
          2) Dropping the workaround of #242 for schema2template as the same difficulties occur for the working environment. Notes are generated apparently at random - observed beyond Ubuntu and Windows with latest (b22) Oracle JDK.

          Show
          Svante Schubert added a comment - Created an attachment (id=433) ZIP containing two patches adding .hgeol (see 161) and new ODF RelaxNG to odfdom~schema2template and odfdom~developer When I created the new files under Windows, I noticed that all files are flagged as changed. This made the review of changes difficult under Windows. The reason therefore was that all files where created in UNIX line ending. In order to see in Mercurial 'hg status' only those files with content changes, I made this document dependent of ODFTOOLKIT-99 and added to the .hgignore the suffix of the Velocity templates file. By doing so the templates within src\codegen\resources\dom\template are checked out according the platform. This patch is similar to the previous two patches with two difference: 1) They are based on the patches of issue #161 2) Dropping the workaround of #242 for schema2template as the same difficulties occur for the working environment. Notes are generated apparently at random - observed beyond Ubuntu and Windows with latest (b22) Oracle JDK.
          Hide
          Svante Schubert added a comment -

          Hi Devin,

          Could you please review this issue?
          AFAIK had Rob asked for an update of the ODF validator in the last ODF Toolkit steering comittee meeting and this patch is relevant for the validators update.

          Regards,
          Svante

          Show
          Svante Schubert added a comment - Hi Devin, Could you please review this issue? AFAIK had Rob asked for an update of the ODF validator in the last ODF Toolkit steering comittee meeting and this patch is relevant for the validators update. Regards, Svante
          Hide
          Svante Schubert added a comment -

          Hi Devin,

          the generated sources are not part of the zipped patch and have to be created by
          "mvn -P codegen"
          When generating the sources three times, I had the first two times different build issues, which appear that issue 242 appears not only in the test enviromenment.

          Regards,
          Svante

          Show
          Svante Schubert added a comment - Hi Devin, the generated sources are not part of the zipped patch and have to be created by "mvn -P codegen" When generating the sources three times, I had the first two times different build issues, which appear that issue 242 appears not only in the test enviromenment. Regards, Svante
          Hide
          Svante Schubert added a comment -

          Created an attachment (id=435)
          The uploaded ZIP is a patch that is based on the previous combined patch, but includes now all new generated ODFDOM sources.

          The source code generation works without any problems under XP 32bit using
          java version "1.6.0_22"
          Java(TM) SE Runtime Environment (build 1.6.0_22-b04)
          Java HotSpot(TM) Client VM (build 17.1-b03, mixed mode, sharing)

          Perhaps issue 242 is only a 64bit Java problem..

          The uploaded ZIP is a patch that is based on the previous combined patch, but includes now all new generated ODFDOM sources.

          Thanks in advance for a review,
          Svante

          Show
          Svante Schubert added a comment - Created an attachment (id=435) The uploaded ZIP is a patch that is based on the previous combined patch, but includes now all new generated ODFDOM sources. The source code generation works without any problems under XP 32bit using java version "1.6.0_22" Java(TM) SE Runtime Environment (build 1.6.0_22-b04) Java HotSpot(TM) Client VM (build 17.1-b03, mixed mode, sharing) Perhaps issue 242 is only a 64bit Java problem.. The uploaded ZIP is a patch that is based on the previous combined patch, but includes now all new generated ODFDOM sources. Thanks in advance for a review, Svante
          Hide
          devin added a comment -

          Hi Svante,

          While you are commentting, I have reviewed and pushed your patch
          Generate sources by myself.
          Close this issue and go to sleep now.

          Devin

          Show
          devin added a comment - Hi Svante, While you are commentting, I have reviewed and pushed your patch Generate sources by myself. Close this issue and go to sleep now. Devin
          Hide
          Svante Schubert added a comment -
          Show
          Svante Schubert added a comment -

            People

            • Assignee:
              devin
              Reporter:
              Svante Schubert
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development