-
Notifications
You must be signed in to change notification settings - Fork 46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Regeneration of ODFDOM DOM sources for ODF 1.2 #135
Comments
Wow! I had no idea code generation was used in this project. Not knowing anything about the code base, here are some random thoughts. If manual edits have been made on classes created by code generation, then I would really avoid replacing those classes by their newly re-generated versions. I think the approach you are adopting (running code generation independently for ODF 1.2 and 1.3 and spotting the differences) is good: those changes then need to be backported manually to the code base. In any case this sounds like a really significant project which should really not be a prerequisite for releasing what you have already. |
Basics of Code Generation UpdateCurrently, the Code generation can only be triggered by the following Java test The generated output - the ODF dom and pkg Java sources - can be found within: The Apache velocity templates, which are being used to generate the ODFDOM Java sources, are from now only with the related (ODFDOM) project: |
There had been an OASIS ODF 1.3 release, but before generating the DOM classes from the XML schema (RNG grammar), it might be a good idea to regenerate the classes for ODF 1.2 again to easily spot the differences between ODF 1.2 and 1.3 (reduce the noise & be sure still everything works as it is expected).
That was supposed to be a quick task, but I had to realize that the generation was not done for a long time and many manual changes were made upon these classes.
I have created the branch odf12-codegen and addressed all the problems that I found worthy to be addressed for the next release - still, some build problems have to be fixed now manually.
There are some fundamental problems in some new hand-written classes, where some low-level XML related class is inheriting from a semantic high-level class (in theory the syntax is exchangeable and an implementation detail), which should be addressed later latest for a 1.0.
The text was updated successfully, but these errors were encountered: