Age | Commit message (Collapse) | Author |
|
Hopefully this will catch future breakages.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=272969420
|
|
- Move nearly all Javadoc configuration to the parent POM.
- Update Guava and ICU4J link locations. The current links resolve to the Javadoc -- but only after a redirect, which Javadoc doesn't like: https://bugs.openjdk.java.net/browse/JDK-8190312
- Update maven-javadoc-plugin to 3.1.1. (This version knows how to work around the aforementioned redirect problem, should it happen again.)
- Add links to Checker Framework. For some reason, this isn't working under Java 11. I haven't investigated.
- Disable detectJavaApiLink, and fill in https://docs.oracle.com/javase/9/docs/api/ for Java 8 and https://docs.oracle.com/en/java/javase/11/docs/api/ for newer versions. (I've tested only with Java 8 and 11, so hopefully the "newer versions" behavior is OK for 9 and 10.)
It does look like it may be necessary to duplicate all the links in 3 places :\
This is all in service of preventing:
[ERROR] Exit code: 1 - javadoc: error - The code being documented uses modules but the packages defined in https://docs.oracle.com/javase/9/docs/api/ are in the unnamed module.
Traditionally we solve this problem by setting <source>8</source> on Javadoc (CL 235241314, CL 236159968). That would probably work here, but I've been experimenting with <source>9</source> (for proper modules support in jimfs), so that might not be an option soon. Or maybe it still would be, but I'd have to exclude module-info.java, but then I wonder if that will trigger modules problems? In any case, it seems more future-proof to solve this the right(?) way.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=272937179
|
|
If run in the old style, it uses javac9, which can't handle the Java 11 class files in the JDK11 bootclasspath.
This follows the instructions at https://errorprone.info/docs/installation#maven
Note also the need to include -Xep:BetaApi:OFF in the same arg as -Xplugin:ErrorProne: https://github.com/google/error-prone/issues/1136#issuecomment-427816741 https://github.com/google/error-prone/pull/1115
(Also, incidentally update Error Prone itself. I forget whether I had a Java-11-related reason for that, but it seems like a good idea.)
RELNOTES=n/a
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=272934125
|
|
Fixes #90
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=272930832
|
|
I was going to say that this also paves the way for including the annotation as a non-optional dependency, should we wish to follow our Guava precedent for annotations:
- https://github.com/google/guava/issues/2824
- https://github.com/google/guava/issues/2721
But I see that it's retention=SOURCE anyway, so there isn't much reason to do that -- except maybe consistency with other annotation packages someday. (Maybe it's still a negative then, as it might still let people rely on our transitive dependency?)
I think the relationship of all this to Java 11 was that I might have to set an Automatic-Module-Name on AutoService, and it makes more sense to set it after we've done the processor-vs.-annotation artifact split. Once I was upgrading, it made sense to set up the annotation processor the Right Away, now that we're using a version in which that works. (Or maybe it always worked but now it's nice that it gets the processor off the classpath?) Or maybe there was some other reason for the change to the annotation-processor setup; once again, I forget. It looks like it might have been that AutoService stops running when I switch how we run Error Prone. Hopefully this was the solution :) But it's probably a good idea in any case.
This CL is basically following the "alternatively" instructions in https://github.com/google/auto/blob/master/value/userguide/index.md#in-pomxml
...even though the AutoService instructions haven't been similarly updated yet: https://github.com/google/auto/tree/master/service#download
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=272720556
|
|
- We may want an ICU4J new enough to contain an Automatic-Module-Name.
- Our old maven-surefire-plugin breaks with NullPointerException with JDK10+: https://bugzilla.redhat.com/show_bug.cgi?id=1572708
- Our old maven-compiler-plugin breaks with JDK11: https://github.com/google/error-prone/issues/1136#issuecomment-427816741 (I don't have the error message handy anymore.)
RELNOTES=n/a
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=272714574
|
|
- Mostly migrate to Checker Framework declaration annotations.
- Migrate @GuardedBy to a custom annotation for now. (We would migrate to Error Prone's, but that's causing me problems as I experiment with JPMS.)
Compare to b/69411537 for Guava.
I've left @ParametersAreNonnullByDefault in place for now, but we'd need to remove it to fully eliminate the jsr305 dep.
RELNOTES=Migrated from jsr305 `@Nullable` to Checker Framework `@NullableDecl`. In addition to the new dependency on the Checker Framework annotations, we keep the dependency on jsr305 for now so that we can keep using `@ParametersAreNonNullByDefault`.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=272713254
|
|
Renames may include:
- containsAllOf => containsAtLeast
- containsAllIn => containsAtLeastElementsIn
- isSameAs => isSameInstanceAs
- isOrdered => isInOrder
- isStrictlyOrdered => isInStrictOrder
The other major change is to change custom subjects to extend raw Subject instead of supplying type parameters. The type parameters are being removed from Subject. This CL will temporarily produce rawtypes warnings, which will go away when I remove the type parameters (as soon as this batch of CLs is submitted).
Some CLs in this batch also migrate calls away from actualAsString(). Its literal replacement is `"<" + actual + ">"` (unless an object overrides actualCustomStringRepresentation()), but usually I've made a larger change, such as switching from an old-style "Not true that..." failure message to one generated with the Fact API. In that case, the new code usually contains a direct reference to this.actual (a field that I occasionally had to create). Another larger change I sometimes made is to switch from a manual check-and-fail approach to instead use check(...). And sometimes I just remove a withMessage() call that's no longer necessary now that the code uses check(...), or I introduce a check(...) call. (An assertion made with check(...) automatically includes the actual value from the original subject, so there's no need to set it again with withMessage().)
Finally, there's one CL in this batch in which I migrate a Correspondence subclass to instead use Correspondence.from.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=251486146
|
|
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=244875885
|
|
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=225212188
|
|
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=191475833
|
|
This is necessary to build with JDK9.
(You can still build *for* older versions of Java to maintain compatibility; this is just to work with build tools from JDK9, as will become the Google default.)
As part of that, migrate from additionalparam, which was deprecated and removed last year, to additionalOptions.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=182543366
|
|
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=177639026
|
|
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=176378503
|
|
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=175893610
|
|
While we're at it, update the snapshot version (tentatively) to 2.0 and update a couple dependency versions.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=114616654
|
|
should be enough
|
|
In particular, auto-service 1.0-rc2 fixes a bug in rc1 that made it not work at all on Windows.
Fixes github issue #25.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=103937809
|
|
Fixes an issue with calls to assertAbout that I introduced in the formatting CL.
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=95118916
|
|
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=86625076
|
|
<reportPlugins>.
This is apparently the preferred way to do this... the previous way shows errors in my IDE.
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=83279354
|
|
under JDK8.
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=79360036
|
|
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=79281813
|
|
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=72563991
|
|
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=67288920
|
|
Update the maven conf to build an OSGi bundle
|
|
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=66919555
|
|
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=65120857
|
|
|
|
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=62208423
|
|
deployed to sonatype staging.
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=62165253
|
|
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=61398492
|
|
META-INF/services file.
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=60126893
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
slow.
|
|
|
|
|
|
|
|
explicitly unsupported.
Also clean up a few TODOs.
|
|
|
|
|
|
Parent project is jimfs-parent with subprojects jimfs and jimfs-benchmarks.
|