| commit | 1e476813416ae1423f28a11ede52c93a32f51eaa | [log] [tgz] |
|---|---|---|
| author | cpovirk <cpovirk@google.com> | Tue Jan 09 08:06:09 2018 -0800 |
| committer | Chris Povirk <beigetangerine@gmail.com> | Tue Jan 09 14:14:53 2018 -0500 |
| tree | 551231383750393365b1ef1fa2670358af6c163b | |
| parent | 7a0a1282763927c5930c65e20de6b6ac58679a44 [diff] |
Fix maven-javadoc-plugin problem in a better way. This replaces CL 180846017. I still don't completely understand what's going on here: Sometimes, maven-javadoc-plugin-2.7 tries to fork off maven-javadoc-plugin in its children. It sounds like it probably shouldn't? But whether it should or not, I really doubt that it should be forking maven-javadoc-plugin-2.7 specifically, rather than respecting its children's versions. And yet that's what it's doing. The bug was apparently fixed in maven-javadoc-plugin 2.8, so all we need to do is upgrade to that. But we might as well go all the way to 3.0.0, which is what we're using for the "real" Javadoc work. (It would be nice if Maven reported a warning about how the build depends on the version of maven-javadoc-plugin chosen here, as I think it sometimes does.) This is probably https://issues.apache.org/jira/browse/MJAVADOC-275. Other times, maven-javadoc-plugin-2.7 *doesn't* try to immediately fork off maven-javadoc-plugin in its children. Yet when those children run later on, they still use 2.7, even though they're configured to use 3.0.0 (because the parent pom's pluginManagement section configures it and their <build> sections are set up to include maven-javadoc-plugin). This sounds like potentially a separate issue, in which configuration (not just the version but also things like -Xdoclint) is lost. I'm not sure how to force one failure mode over the other. I thought maybe that I needed something like `find $HOME/.m2/repository/com/google/truth -name '1.0-SNAPSHOT' | xargs rm -rf` or `mvn versions:set versions:commit -DnewVersion=0.99`, but neither of those is sufficient. I'm also not sure if the first failure mode really matters: Regardless of when the child plugin runs, it is going to run without its inherited configuration because of the second failure mode. And the lack of inherited configuration is what made the run fail (because of lint errors). In any case, using 3.0.0 in the parent (which didn't even declare a maven-javadoc-plugin section) fixes the problem without needing to duplicate configuration in child poms. Should we need to reproduce the problem again: - Check out 75e60e23406ef39af41e831355646c4b95d0d14a. - Edit files like pom.xml and core/pom.xml as desired. - Run `mvn clean site:jar install -P sonatype-oss-release -DskipTests`. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=181320904
Truth is an assertion framework for Java tests, inspired by FEST, and driven by some extensibility needs, written nearly entirely by Google employees in their spare time or contributing in their capacity as Java core librarians.
Truth can be used in place of JUnit‘s assertions, FEST, or Hamcrest’s matchers, or it can be used alongside where other approaches seem more suitable.
The full documentation for Truth is available at its main website
Truth is licensed under the open-source Apache 2.0 license.
Please see the guidelines for contributing before creating pull requests.
Thanks to Github and Travis-CI for having a strong commitment to open-source, and providing us with tools so we can provide others with code. And thanks to Google for Guava, for taking on the Truth project and making it part of their core-libraries effort, and for encouraging us to try to solve problems in better ways and share that with the world.
Also thanks to the authors of JUnit, TestNG, Hamcrest, FEST, and others for creating testing tools that let us write high-quality code, for inspiring this work and for moving the ball forward in the field of automated software testing. This project works with, works alongside, and sometimes works in competition with the above tools, but owes a debt that everyone owes to those gone before. They paved the way, and we hope this contribution is helpful to the field.