This plugin is specifically built for libraries. The major difference to the regular java plugin is that is allows defining dependencies as part of the api or implementation. Both are used by the project at compile/runtime, but only api dependencies are made available to dependent projects.
In our current setup, this doesn't matter much. We deploy to maven central using pre-built POMs. It's more of a future-proofing, and it makes it a little bit clearer which gradle projects actually require which dependencies.
git-svn-id: https://svn.apache.org/repos/asf/poi/trunk@1887650 13f79535-47bb-0310-9956-ffa450edef68
We do not make use of the batik-script dependency. While this is likely to be true of a variety of the Batik dependencies, batik-script causes problems for our users who are using JPMS. See [bug-65103].
Fixes#230
git-svn-id: https://svn.apache.org/repos/asf/poi/trunk@1887643 13f79535-47bb-0310-9956-ffa450edef68
Batik-all is a strange artifact. It's POM declares dependencies on all the sub-JARs, but its JAR has all of the sub-jars repackaged. This results in multiple JARs with the same packages being added to consuming applications. This leads to problems for JPMS users. See [bug-65183].
The Ant build does not use batik-all, so the Maven and Gradle builds should not either.
git-svn-id: https://svn.apache.org/repos/asf/poi/trunk@1887642 13f79535-47bb-0310-9956-ffa450edef68
Something is causing parallel tests to fail on CI. I haven't been able to track down what it is. The symptoms look similar to others where the cause was a test modifying the test-data directory.
The integration tests also sometimes run into OutOfMemoryErrors when I run them in parallel.
git-svn-id: https://svn.apache.org/repos/asf/poi/trunk@1887631 13f79535-47bb-0310-9956-ffa450edef68
Some tests modify global resources. Those tests cannot be run in parallel with others, as they cause problems or become flaky. Where possible, indicate to JUnit the resources in contention. Otherwise, mark the tests as needing to run in isolation.
git-svn-id: https://svn.apache.org/repos/asf/poi/trunk@1887630 13f79535-47bb-0310-9956-ffa450edef68
Reduce the number of map lookups necessary to compute the return values for methods that return collections of property details. Since we maintain parity between the `props` and `dictionary` contents, when retrieving property details, we can reference the `props` directly and avoid the `dictionary` indirection.
git-svn-id: https://svn.apache.org/repos/asf/poi/trunk@1887453 13f79535-47bb-0310-9956-ffa450edef68
The [MS-PPT] spec is very clear about what the format of the PPDrawing record must be, and parsing deterministically makes for clearer code.
git-svn-id: https://svn.apache.org/repos/asf/poi/trunk@1887396 13f79535-47bb-0310-9956-ffa450edef68
Recently, while debugging app behavior on HSLF documents, I had to dig into the OOXML that Microsoft PowerPoint places into files saved in PPT format. Having information in the logs about when records were not parsed by POI was very helpful. The hex identifier was critical in being able to quickly search the [MS-PPT] spec for what type of record it was, and the integer identifier was helpful in quickly finding the Record type in RecordTypes.java.
git-svn-id: https://svn.apache.org/repos/asf/poi/trunk@1887393 13f79535-47bb-0310-9956-ffa450edef68
Andreas Beeker
PJ Fanning
Dominik Stadler
Sayi
Marius Volkhart
Nick Burch