Skip to content
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

Closed
Cypher1 opened this issue Mar 26, 2020 · 4 comments · Fixed by #672
Closed

Api pages break when searching #670

Cypher1 opened this issue Mar 26, 2020 · 4 comments · Fixed by #672

Comments

@Cypher1
Copy link

Cypher1 commented Mar 26, 2020

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)

@cpovirk
Copy link
Member

cpovirk commented Mar 26, 2020

Ugh -- thank you for reporting. Going to try this.

@cpovirk
Copy link
Member

cpovirk commented Mar 26, 2020

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 :)) DoubleSubject, which might even be marginally faster than Javadoc's built-in search (which, again, we should still fix).

@cpovirk
Copy link
Member

cpovirk commented Mar 26, 2020

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:
https://truth.dev/api

(Maybe you're aware of all this, but I can't miss the opportunity to plug it :))

nick-someone pushed a commit that referenced this issue Mar 26, 2020
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
nick-someone pushed a commit that referenced this issue Mar 26, 2020
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
@Cypher1
Copy link
Author

Cypher1 commented Mar 26, 2020

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants