slachiewicz opened a new pull request, #154: URL: https://github.com/apache/maven-doxia-converter/pull/154
`ReaderFactory` and `WriterFactory` are deprecated at class level in plexus-utils 4. The substitutions are the factory bodies themselves: | was | now | |---|---| | `newXmlReader(f)` | `XmlStreamReader.builder().setFile(f).get()` | | `newReader(f, enc)` | `new InputStreamReader(Files.newInputStream(..), enc)` | | `newPlatformReader(f)` | `Files.newBufferedReader(f.toPath())` | | `newXmlWriter(f)` | `XmlStreamWriter.builder().setFile(f).get()` | | `UTF_8` | `StandardCharsets.UTF_8.name()` | Two choices worth explaining, since this is an encoding-sensitive tool: **Why Commons IO and not plexus-xml.** `DefaultConverter` already used Commons IO's `XmlStreamReader` to sniff the encoding of a source file — the most encoding-sensitive thing the converter does. Routing the remaining XML reads through the same implementation means one thing decides encoding everywhere, rather than two implementations of the same algorithm sitting side by side. **Why builders.** Every Commons IO constructor for `XmlStreamReader` and `XmlStreamWriter` is itself deprecated in favour of `builder()`, so using the constructors would trade one deprecation for another. The pre-existing sniffing call moves to a builder for the same reason. `plexus-utils` stays a dependency regardless — `PathTool`, `SelectorUtils` and `Os` are unaffected. Verified: 23 tests pass, and the shaded CLI converting apt→Markdown, an apt tree→XHTML, and xdoc→XHTML produces output byte-identical to the same jar built from master. The xdoc run exercises the changed XML reader path. *This change was created with AI assistance.* -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
