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
Add matchingRegex #598
Add matchingRegex #598
Conversation
Hi, since this PR was created a lot of dokka has changed. Would you mind rebasing it onto master? |
Yup, give me a bit of time to switch back to this and I'll rebase. |
Right now dokka has a prefix option in |
e85a18c
to
a5081a8
Compare
@MarcinAman PR is rebased. Removing |
@@ -28,8 +28,8 @@ fun PreMergeDocumentableTransformer.sourceSet(documentable: Documentable): Dokka | |||
fun PreMergeDocumentableTransformer.perPackageOptions(documentable: Documentable): PackageOptions? { | |||
val packageName = documentable.dri.packageName ?: return null | |||
return sourceSet(documentable).perPackageOptions | |||
.sortedByDescending { packageOptions -> packageOptions.prefix.length } | |||
.firstOrNull { packageOptions -> packageName.startsWith(packageOptions.prefix) } | |||
.sortedByDescending { packageOptions -> packageOptions.matchingRegex.length } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This feels a bit awkward with regexes. I think I would prefer the order of the rules in the Gradle file to determine priority but I'll let people more familiar with the subject decide.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think ordering in Gradle might be more problematic and potentially could break easier. Also it will cause some confusion especially when having split logic for dokka configuration (eg. some packageOptions in buildSrc and some in Gradle build files), so I'd personally stick with the regex for now
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair point about split logic, especially since it's hard to know in advance the order of execution of Gradle scripts. I added a small note to the Gradle documentation to tell users that the longuest matchingRegexp will be used.
For the cli
usage, maybe the order of arguments would still make sense? Or ultimately, maybe an explicit priority
option will be needed. But this can be all be added later depending the needs and use cases
It can be shipped, as for now Dokka doesn't have any guarantees about stability. Thanks, i'll check out the changes tomorrow 👍 |
@@ -28,8 +28,8 @@ fun PreMergeDocumentableTransformer.sourceSet(documentable: Documentable): Dokka | |||
fun PreMergeDocumentableTransformer.perPackageOptions(documentable: Documentable): PackageOptions? { | |||
val packageName = documentable.dri.packageName ?: return null | |||
return sourceSet(documentable).perPackageOptions | |||
.sortedByDescending { packageOptions -> packageOptions.prefix.length } | |||
.firstOrNull { packageOptions -> packageName.startsWith(packageOptions.prefix) } | |||
.sortedByDescending { packageOptions -> packageOptions.matchingRegex.length } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just one request to remove the unnecessary (I believe) check and it should be good to go
@@ -7,8 +7,8 @@ import java.util.function.BiConsumer | |||
|
|||
|
|||
fun parsePerPackageOptions(args: List<String>): List<PackageOptions> = args.map { it.split(",") }.map { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this check is now unnecessary as we dropped global settings and I see no reason why the regex could not be an all match
@@ -28,8 +28,8 @@ fun PreMergeDocumentableTransformer.sourceSet(documentable: Documentable): Dokka | |||
fun PreMergeDocumentableTransformer.perPackageOptions(documentable: Documentable): PackageOptions? { | |||
val packageName = documentable.dri.packageName ?: return null | |||
return sourceSet(documentable).perPackageOptions | |||
.sortedByDescending { packageOptions -> packageOptions.prefix.length } | |||
.firstOrNull { packageOptions -> packageName.startsWith(packageOptions.prefix) } | |||
.sortedByDescending { packageOptions -> packageOptions.matchingRegex.length } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think ordering in Gradle might be more problematic and potentially could break easier. Also it will cause some confusion especially when having split logic for dokka configuration (eg. some packageOptions in buildSrc and some in Gradle build files), so I'd personally stick with the regex for now
Thanks |
You can check out the build with your changes by adding a new repository: |
* add matchingRegex as a simpler replacement for `prefix` * remove useless check * added a note about the order of the matchingRegex
Closes #593
This allows to match a package based on a regex and not only a prefix.