Add wildcard support for exclusion rules

[rvandermeulen]

Is your feature request related to a problem? Please describe.
Right now, if I want to ignore multiple packages from the same project, I have to list each one individually. And the rules need to be updated any time a new package from that project gets added. This can be a bit cumbersome.

Describe the solution you'd like
Add wildcard support to the exclude rules, so something like exclude('project:*') would work.

Describe alternatives you've considered
Excluding each individually.

Additional context
N/A

[autonomousapps]

Thanks for the issue.

Can you explain why you have this need to exclude so many things? Is there some issue with the analysis?

[jonapoul]

+1 for me. Personally, I'd like it because I keep module diagrams of my projects to illustrate how modules link together. Unless I can exclude projects from onIncorrectConfiguration, I'm forced to add loads of interleaving direct links between nodes in the diagram, which makes the whole thing more difficult to follow.

Ideally I'd make most of those links api instead of implementation, which IMO is easier to understand.

[rvandermeulen]

Thanks for the issue.

Thanks for the reply and for creating this tool in the first place!

Can you explain why you have this need to exclude so many things? Is there some issue with the analysis?

Certainly. I have two main cases in mind for this:

• Multiple modules from the same project that I'm knowingly bringing in transitively and OK with (for example, hamcrest coming by way of junit was one that I encountered when first setting up DAGP on a project - I'm perfectly fine with those being managed upstream and find one-by-one excluding to be cumbersome)
• More specific to our project's use case, we (Mozilla) build have Nightly, Beta, and Release build variants that all come from the same repo. There are a couple transitive dependencies for other libraries we control, but their exact name depends on the channel (i.e. blahblah-nightly, blahblah-beta, etc). If I'm going to accept these being transitive dependencies (and I am since we control the libraries in question and are assured that we're using the expected version for each project), I need to list all the variants individually instead being able to just use a single entry with a wildcard instead.

Hopefully that makes sense. Happy to try to clarify anything if needed.

[autonomousapps]

Unless I can exclude projects from onIncorrectConfiguration

So you're saying you prefer to have incorrectly declared dependencies? I'm not sure I want to make that easier to do.

[autonomousapps]

I suspect that you might find the bundle feature very useful for meeting your needs. It already permits regex.

https://github.com/autonomousapps/dependency-analysis-gradle-plugin/wiki/Customizing-plugin-behavior#logical-dependency-groups-aka-dependency-bundles

[rvandermeulen]

I'm having a bit of difficulty figuring out how to apply bundles to our situation.

I would have expected behavior something along the lines of #904 but obviously that's not how they're designed to work. I'm not seeing how to make the connection between defining a bundle and telling the plugin to ignore any transitive dependencies applicable to it.

[rvandermeulen]

@autonomousapps Maybe I'm misunderstanding how bundles are meant to work. Do I need to create a bundle which is chained up to the parent dependency that pulls in the transitive ones I'm trying to ignore?

[autonomousapps]

So I think what you might want is something like this:

// build.gradle
dependencyAnalysis {
  structure {
    bundle("project-group") { // name is arbitrary but must be unique
      primary(":name-of-project-with-api-deps") // the project dep you want to declare
      include(":<regex that matches the projects you don't want to have to declare>")
    }
  }
}

[rvandermeulen]

Thanks, I'll play around with that!