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

Add matchingRegex #598

Merged
merged 3 commits into from Nov 18, 2020
Merged

Add matchingRegex #598

merged 3 commits into from Nov 18, 2020

Conversation

martinbonnin
Copy link
Contributor

Closes #593

This allows to match a package based on a regex and not only a prefix.

            perPackageOption {
                matchingRegex = ".*\\.internal"
                suppress = true
            }

@MarcinAman
Copy link
Contributor

Hi, since this PR was created a lot of dokka has changed. Would you mind rebasing it onto master?

@martinbonnin
Copy link
Contributor Author

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.

@MarcinAman
Copy link
Contributor

Right now dokka has a prefix option in PackageOptions. I think it would be worth to change that to your regex-based approach to make it more powerfull, i dont feel like we need 2 options to configure more or less same thing

@martinbonnin martinbonnin changed the base branch from dev-0.10.1 to master November 11, 2020 15:02
@martinbonnin
Copy link
Contributor Author

@MarcinAman PR is rebased. Removing prefix is technically a breaking change, let me know if that can be shipped at this stage or if you want me to add it again with a deprecation warning (which will complexify both the documentation and the handling of default values but hey, it happens!)

@@ -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 }
Copy link
Contributor Author

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

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

Copy link
Contributor Author

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

@MarcinAman
Copy link
Contributor

@MarcinAman PR is rebased. Removing prefix is technically a breaking change, let me know if that can be shipped at this stage or if you want me to add it again with a deprecation warning (which will complexify both the documentation and the handling of default values but hey, it happens!)

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 }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

@kamildoleglo kamildoleglo left a 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 {
Copy link
Contributor

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 }
Copy link
Contributor

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

@MarcinAman MarcinAman merged commit 1959b91 into Kotlin:master Nov 18, 2020
@MarcinAman
Copy link
Contributor

Thanks ☺️

@MarcinAman
Copy link
Contributor

You can check out the build with your changes by adding a new repository: maven("https://maven.pkg.jetbrains.space/kotlin/p/dokka/dev") and updating version to: 1.4.20-dev-23

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 this pull request may close these issues.

Allow to apply perPackageOption based on a regex, not only prefix
3 participants