I have tested (as previously described) JApiCmp to identify the API changes
on the odf-codgen branch for ODF code generation
The HTML report file
a bit noisy, as in the now updated code generation the base/super
class feature - for reuse of elements attributes and child elements - had
The report is about 27 DINA4 pages long and I will highlight the reasons
for some changes.
Earlier API Problem: Visible after fix of Base Class Handling
As you can see from the grammar-additions.xml
there are 5 base classes being generated:
1. DrawShapeBase (with 17 subclasses)
2. NumberDataStyleBase (with 7 subclasses)
3. TableTableCellBase (with 2 subclasses)
4. TextListLevelStyle (with 3 subclasses)
5. TextParagraphBase (with 2 subclasses)
I can not remember who had sent the requirements to those base classes but
I assume it was Sun's web office team.
There was a problem with the DrawShapBase in the previous API: if you
consult the previous JavaDoc
you will notice method access to @svg:height attribute
you may find several subclasses (like for for <draw:connector>
which does not offer such an attribute
That is the reason for the API removal mentioned within the HTML report for
as now the base class generation was fixed.
On other occasions shared attributes & children were still in the
subclasses and have now been moved to the base class. But I guess this API
change should make no difference as the same functionality is being offered.
Nevertheless, the HTML report marks this as delete and new API and not as a
move of an API to its superclass (simply "text search" for it within the
report and you will notice its movement).
Nice2Have: The generation of Interfaces for semantic-groups
I had to fix the API due to the removal of svg:height and circumventing the
problem by accessing directly DOM API, but it would be nice to add
interfaces for those shapes sharing height/width attributes allowing
grouping and subclassing in the future. Uncertain how these
Interfaces could be easily found (perhaps even by some
heuristics/automation)? The definition in the RNG grammar file of ODF might
be a hint. A more general hint would be an RNG grammar analysis returning
the elements with the most shared attributes as Interface candidates.
Nice2Have: The generation of ODF element constructors with all mandatory
This is something for "later" to offer a constructor for an ODF element
with all its mandatory attributes and those from the mandatory element
children, and so on...
But I already missed this feature... and removed the manually added
constructor from NumberBooleanStyleElement
API Problem: NumberTextStyleElement and NumberBooleanStyleElement
I hate to say it, but it was probably me!
All other data styles were abstract and convenience API was added by
inheriting from the ODF convenience class (e.g. ), but not for the
where I added the functionality once in the generated code. I made it
consistent some weeks ago by making those two elements abstract and adding
a new subclass below before I adopted the generated to insert such
functionality on demand.
If this is already too annoying for you, I might be willing to turn this
change back. Sorry for any inconvenience!
No API Problem: Removal getValue() / setValue()
The deletion of these getValue()/setValue() methods
which were earlier generated but are identical with methods provided by
Xerces XML parser implementation. There should be no problem!
For instance, the current getValue() of InitialisationVectorAttribute
be replaced by its inherited getValue() of AttrImpl (Xerces)
you can see in the latest JavaDoc of InitialisationVectorAttribute
Any new API added and listed is not a problem!
Should there be any further changes/problems in the report I have noticed
or in case you have any further suggestions, please drop me a line!
Perhaps there are already unknown better tooling for Java API changes out
To unsubscribe e-mail to: email@example.com
Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette
List archive: https://listarchives.odftoolkit.org/dev/
- [dev] ODFDOM API Changes on branch odf-codegen (reactivating ODF code generation) · Svante Schubert
Impressum (Legal Info)
: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (MPLv2
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our trademark policy