WARNING of 2018 08 03: this release writes <?xml version="1.0" ?> omitting encoding "UTF-8". Although UTF-8 is supposed to be the default encoding for XML, it is possible that some consumers may behave incorrectly. Users are advised not to deploy v6.0.0 to production. v6.0.1 will be released shortly, containing the change at https://github.com/plutext/docx4j/commi ... b45ef6e9ba which makes the encoding explicit.
Docx4j 6.0.0 is now available.
Rather than calling it 3.4.0, it is called 6.0.0 since it still supports Java 6. (The plan is that docx4j 7.x, when released, will require Java 7+, and so on. Easy to remember.)
This release contains the following notable changes:
- support for Java 9 and 10
- preserve mc:AlternateContent in a run
New dependency commons-compress used for zip/unzip. Most other deps updated to last version supporting Java 6.
API breaking changes have largely been avoided, so it should be easy to get your code running against this.
You can get it with deps at https://docx4java.org/docx4j/docx4j-community-6.0.0.zip or just the jar https://docx4java.org/docx4j/docx4j-6.0.0.jar (you'll want commons compress too, from https://docx4java.org/docx4j/docx4j-6_0 ... s-1.12.jar )
For Maven users, it is also in the Central Repository at http://search.maven.org/#search%7Cga%7C ... .docx4j%22
cheers .. Jason
Notable Changes in Version 6.0.0
Support for Java 9 and 10 (see notes in README for use in Eclipse)
- Maven profiles for java 9 and 10
- Maven pom now specifies source & target 1.6 (previously 1.5)
Preserve mc:AlternateContent in a run. Previously, this would have caused mc-preprocessor
to be invoked, selecting one of the pieces of content.
Object model for wps http://schemas.microsoft.com/office/wordprocessingShape
Content Control databinding (and OpenDoPE)
- UpdateXmlFromDocumentSurface: Copy content control content back to the custom XML part, like Microsoft Word does for a content control which has a w:databinding element
- improvements to migration (from eg VariableReplace)
- better support for binding standardised Answers format
- various other improvement
Write docx4j version as XML comment in MainDocument part.
New properties docx4j.openpackaging.parts.MAX_BYTES.unzip.error and docx4j.openpackaging.parts.MAX_BYTES.unmarshal.error which can be set to positive values to have docx4j throw a PartTooLarge exception if a part is larger than the set value.