-
Notifications
You must be signed in to change notification settings - Fork 260
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Api pages break when searching #670
Comments
Ugh -- thank you for reporting. Going to try this. |
Also, this is as good a chance as any to advertise my favorite recent addition to Truth (and Guava): We set up redirects for URLs like the following: https://truth.dev/doublesubject That will take you directly to (the correct location of :)) |
That fix appears to work. (The warnings about breaking JDK links don't apply in our case. Details in internal CL 303110325, which will get mirrored out soon if all goes well.) While I'm talking about short links: You can get to the Javadoc index with: (Maybe you're aware of all this, but I can't miss the opportunity to plug it :)) |
I'm using the fix from https://stackoverflow.com/a/52603413/28465 Note that this fix can break links to the JDK Javadoc in some cases (https://stackoverflow.com/a/56394202/28465), and apparently there are alternative solutions that can avoid that (https://stackoverflow.com/a/56641766/28465). However, because we are linking to JDK version *1.7*, we don't need or want module names in those URLs, so this solution works fine for us. Before this CL, our linking to JDK 1.7 happens implicitly based on the -source value for the *compiler* plugin. I've decided that this is as good a time as any to make an explicit choice instead. So my change to link to JDK 1.7 is a no-op. I considerd updating our configuration to point to JDK 1.8 or 1.9, but those use a different format for anchors than the JDK 11 javadoc generates (clone-- vs. clone()), so links to specific methods wouldn't go to those methods anymore. I also tried pointing to JDK 10, which does use the same anchor format as JDK 11 javadoc, but then I run into problems related to modules, and I don't want to get into that. And once you get to JDK 11+, then you need your JDK links to include the module in the URL, so I'd need to explore the alternative fix. *Plus*, I assume I'd have the same other modules problems as I saw with JDK 10. (Note that the --no-module-directories option that I've added doesn't work with JDK 1.8. Neither does the existing --frames option. Ideally, I might put these in a <profile>. But given the number of settings that need to be aligned just right, any of which could potentially interact with the version of javadoc that we're using, it's probably better if we just require a newer version. Ideally I'd set up Maven to require JDK 11 (to ensure that javadoc generates anchors in the format we expect), but I haven't bothered yet.) Fixes #670 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=303114889
I'm using the fix from https://stackoverflow.com/a/52603413/28465 Note that this fix can break links to the JDK Javadoc in some cases (https://stackoverflow.com/a/56394202/28465), and apparently there are alternative solutions that can avoid that (https://stackoverflow.com/a/56641766/28465). However, because we are linking to JDK version *1.7*, we don't need or want module names in those URLs, so this solution works fine for us. Before this CL, our linking to JDK 1.7 happens implicitly based on the -source value for the *compiler* plugin. I've decided that this is as good a time as any to make an explicit choice instead. So my change to link to JDK 1.7 is a no-op. I considerd updating our configuration to point to JDK 1.8 or 1.9, but those use a different format for anchors than the JDK 11 javadoc generates (clone-- vs. clone()), so links to specific methods wouldn't go to those methods anymore. I also tried pointing to JDK 10, which does use the same anchor format as JDK 11 javadoc, but then I run into problems related to modules, and I don't want to get into that. And once you get to JDK 11+, then you need your JDK links to include the module in the URL, so I'd need to explore the alternative fix. *Plus*, I assume I'd have the same other modules problems as I saw with JDK 10. (Note that the --no-module-directories option that I've added doesn't work with JDK 1.8. Neither does the existing --frames option. Ideally, I might put these in a <profile>. But given the number of settings that need to be aligned just right, any of which could potentially interact with the version of javadoc that we're using, it's probably better if we just require a newer version. Ideally I'd set up Maven to require JDK 11 (to ensure that javadoc generates anchors in the format we expect), but I haven't bothered yet.) Fixes #670 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=303114889
Thanks! |
Hitting the first result when searching 'isGreaterThan' in the api documentation leads to the following URL. Which returns a Github Pages page with a 404 error.
https://truth.dev/api/latest/undefined/com/google/common/truth/DoubleSubject.html#isGreaterThan(int)
Something is inserting an
undefined
in the path, the following URL works.https://truth.dev/api/latest/com/google/common/truth/DoubleSubject.html#isGreaterThan(int)
The text was updated successfully, but these errors were encountered: