Fix cross module resolution local links #3425
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The existing behavior was just taking the first module that includes the package name of a given reference, so this resulted in broken links when a package is split across multiple modules. This change checks to ensure the resolved file exists before choosing it as the target for the resolved link. Signed-off-by: Eddie Ringle <[email protected]>
vmishenev
force-pushed
the
vmishenev/2272-fix-cross-module-resolution-local-links
branch
from
c4d81f7 to
af9a5b2
Compare
whyoleg
approved these changes
Dec 21, 2023
...s/gradle/projects/it-multimodule-inter-module-links/gradle/wrapper/gradle-wrapper.properties
Outdated
Show resolved
Hide resolved
...odules-page/src/main/kotlin/org/jetbrains/dokka/allModulesPage/ExternalModuleLinkResolver.kt
Show resolved
Hide resolved
...odules-page/src/main/kotlin/org/jetbrains/dokka/allModulesPage/ExternalModuleLinkResolver.kt
Outdated
Show resolved
Hide resolved
IgnatBeresnev
approved these changes
Jan 9, 2024
vmishenev
force-pushed
the
vmishenev/2272-fix-cross-module-resolution-local-links
branch
from
27ff46c to
32933c7
Compare
|
Thanks for working to get all of this resolved @vmishenev! |
vmishenev
deleted the
vmishenev/2272-fix-cross-module-resolution-local-links
branch
IgnatBeresnev
pushed a commit
that referenced
this pull request
Jan 11, 2024
Fixes #2272. There is a situation where 2 (or more) gradle modules have the same package and dokka doesn’t know where to link. E.g. The class com.example.classA is in moduleA and com.example.classB is in moduleB moduleC depends on moduleA and moduleB. In moduleC: there is a link [com.example.classB]. Having only package-list, dokka doesn’t know where to link, since the package com.example is in both modules. This is short-term and temporary solution of #3368 to cover a case of links between only local modules in a project. It is based on #2901 from @EddieRingle. It generates an external link depending on a check if the local link exists. The check works only when the number of possible resolved links are more than one. * all-modules-page: Validate cross-module links during resolution The existing behavior was just taking the first module that includes the package name of a given reference, so this resulted in broken links when a package is split across multiple modules. This change checks to ensure the resolved file exists before choosing it as the target for the resolved link. Signed-off-by: Eddie Ringle <[email protected]> * Check links only if resolved links has more than one link * Add integration test * Refactor * Add comment --------- Signed-off-by: Eddie Ringle <[email protected]> Co-authored-by: Eddie Ringle <[email protected]> (cherry picked from commit 6904571)
vmishenev
added a commit
that referenced
this pull request
Mar 20, 2024
Fixes #2272. There is a situation where 2 (or more) gradle modules have the same package and dokka doesn’t know where to link. E.g. The class com.example.classA is in moduleA and com.example.classB is in moduleB moduleC depends on moduleA and moduleB. In moduleC: there is a link [com.example.classB]. Having only package-list, dokka doesn’t know where to link, since the package com.example is in both modules. This is short-term and temporary solution of #3368 to cover a case of links between only local modules in a project. It is based on #2901 from @EddieRingle. It generates an external link depending on a check if the local link exists. The check works only when the number of possible resolved links are more than one. * all-modules-page: Validate cross-module links during resolution The existing behavior was just taking the first module that includes the package name of a given reference, so this resulted in broken links when a package is split across multiple modules. This change checks to ensure the resolved file exists before choosing it as the target for the resolved link. Signed-off-by: Eddie Ringle <[email protected]> * Check links only if resolved links has more than one link * Add integration test * Refactor * Add comment --------- Signed-off-by: Eddie Ringle <[email protected]> Co-authored-by: Eddie Ringle <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #2272. There is a situation where 2 (or more) gradle modules have the same package and dokka doesn’t know where to link.
E.g.
The class
com.example.classAis inmoduleAand
com.example.classBis inmoduleBmoduleCdepends onmoduleAandmoduleB.In
moduleC: there is a link[com.example.classB]. Having onlypackage-list, dokka doesn’t know where to link, since the packagecom.exampleis in both modules.This is short-term and temporary solution of #3368 to cover a case of links between only local modules in a project.
It is based on #2901 from @EddieRingle. It generates an external link depending on a check if the local link exists. The check works only when the number of possible resolved links are more than one.
The general solution of #3368 should also cover links to external modules (that are locally unavailable).