[
https://issues.apache.org/jira/browse/MDEP-808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17771907#comment-17771907
]
Francis commented on MDEP-808:
------------------------------
[~elharo]
{quote}
Looking at this again, I'm seeing that everything you want to do is already
possible. You simply want a switch to change from analyze by default to ignore
by default. That's pretty small beans. I'm very tempted to close this as won't
fix to avoid adding complexity to the code and docs unless there's a real need
I'm not seeing.
{quote}
I think the best I can do is to elaborate the need that arose in our
organisation and provide a bit more context over that already stated in the
description.
We have a monobuild that builds over a large monorepo and we want to ensure the
dependency graph is as small as possible. This maximises the throughput in the
monobuild and also ensures that the various tools that developers use to
analyse the dependency graph don't present any superfluous information. We run
analyse upon ~800 artifacts within that monobuild (which is a subset of the
total artifacts, we have an initiative scheduled to further expand the usage).
Currently the pluginManagement block in the parent pom that sits of the
monobuild looks something like this (lightly edited for public consumption):
[^pluginManagementPreMDEP-808.txt]
With the code under this issue, it simplifies to:
[^pluginManagementPostMDEP-808.txt]
So yes, we are already able to achieve the desired functional result, but it
leaves an ugly mess in the pom. Why don't we simply expand the scope of analyze
to run over all dependencies at our organisation and be done with it?
Introducing analyze to the extent that it has been now took ~50 days of
developer effort, and we don't think we'll get the same benefits from expanding
it further to include all dependencies.
[Lifting from the
PR|https://github.com/apache/maven-dependency-plugin/pull/218#pullrequestreview-1657317011]:
{quote}
I'm still skeptical of this feature. What is the problem solved by not warning
on all unused dependencies? Unused dependencies don't break the build. If
someone can't fix them all right now, so what?
{quote}
We *_do_* want unused dependencies to break the build so we *_do_* warn on
them. We've found that is the only really effective way to ensure that unused
dependencies are cleared up, preventing eventual drift such that over time our
monobuild slows down and our graphing tools start lying to our developers about
the actual state of the dependencies.
That's the best case I can make for this. That MDEP-885 has been logged
demonstrates that our use-case isn't the only use-case (but admittedly only
proves there's at least two use-cases).
There are still some outstanding review comments on the PR, but I think it best
if I stop noodling on the PR until the maintainers are sold on the case for
this change, otherwise that's more effort on something that isn't long for this
world.
> Restrict dependency analysis by group id
> ----------------------------------------
>
> Key: MDEP-808
> URL: https://issues.apache.org/jira/browse/MDEP-808
> Project: Maven Dependency Plugin
> Issue Type: New Feature
> Components: analyze
> Affects Versions: 3.3.0
> Reporter: Francis
> Assignee: Elliotte Rusty Harold
> Priority: Minor
> Attachments: pluginManagementPostMDEP-808.txt,
> pluginManagementPreMDEP-808.txt
>
>
> On our project we have elected to run the dependency analysis only over our
> inhouse authored dependencies. We want to run it for our groupId only.
> Unfortunately the project is too mature and the poms would become too bloated
> to run dependency analysis over all the dependencies. Even if this were
> feasible, the real value in our project is having minimally declared
> dependencies over the dependencies we author.
> In order to achieve running the dependency analysis over our {{groupId}}
> only,
> we've excluded third party dependencies by generous use of
> {{ignoredUsedUndeclaredDependencies}} and
> {{ignoredUnusedDeclaredDependencies}}, effectively only building a path to
> our groupId. If the {{groupId}} is {{com.artic}} then we've got a long list
> of exclusions, for example:
> {noformat}
> ...
> <ignoredUsedUndeclaredDependencies>
>
> <ignoredUsedUndeclaredDependency>a*:*:*</ignoredUsedUndeclaredDependency>
> <ignoredUsedUndeclaredDependency>b*:*:*
> <!-- allow "c" as the first part of com -->
> </ignoredUsedUndeclaredDependency>
>
> <ignoredUsedUndeclaredDependency>d*:*:*</ignoredUsedUndeclaredDependency>
> ...
>
> <ignoredUsedUndeclaredDependency>cm*:*:*</ignoredUsedUndeclaredDependency>
>
> <ignoredUsedUndeclaredDependency>cn*:*:*</ignoredUsedUndeclaredDependency>
> <!-- Ignore everything beginning c* excluding co* -->
>
> <ignoredUsedUndeclaredDependency>cp*:*:*</ignoredUsedUndeclaredDependency>
>
> <ignoredUsedUndeclaredDependency>cq*:*:*</ignoredUsedUndeclaredDependency>
> {noformat}
> While this works, it's pretty ugly, and because it sits high up on our pom
> hierarchy it makes it harder to re-use the
> {{ignoredUsedUndeclaredDependencies}} and
> {{ignoredUnusedDeclaredDependencies}} for having to restate all the third
> party dependencies.
> Ideally it would be possible to specify running the dependency analyze for a
> specific groupId only.
> Suggestion is to introduce a new allow list whereby the dependency analysis
> is only run for the groupIds listed. Could also include the artifactId as
> well.
> Suggested name for new parameter is:
> {noformat}
> analyzeDependencies, String[], List of dependencies that will be analysed.
> The filter syntax is:
> [groupId]:[artifactId]
> where each pattern segment is optional and supports full and partial *
> wildcards. An empty pattern segment is treated as an implicit wildcard.
> Omitting this parameter will result in the analysis being run for all
> dependencies.
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
